Codeship is easier to use than Jenkins because it does not require you to set up your own server, and it provides a large amount of out-of-the-box integrations for version control systems and cloud environments. AWS CodePipeline is native to AWS and cannot deploy applications …
Codeship has been easier for our devops team to work with as far as making delivery plans and build scripts. Anecdotally, it has been more stable over time, cutting down on time investigating why some random part of the delivery process has broken. I am not sure why this is, …
We have been using Codeship for a few years, and what we like is that it's very clear what is built and when. We usually only have one-liners for any configuration option (build, test, deploy) and this way all changes to the build are managed in the version control system and …
Our company uses Jenkins for all internal deployment processes for one very important reason - it's hosted internally. But Codeship is great for personal use - it has intuitive UI, easy setup and tons of integrations.
Back in those days, we didn't know about Gitlab, and Bitbucket didn't provide a CI pipeline. Jenkins is just too much for the simple tasks we wanted to achieve, besides, we didn't have a dedicated server for the sole purpose of having our code pipelined though continuous …
I'm a full-stack developer that has used various build tools, including Maven, Gradle, and NPM/yarn. For our C projects, I also investigated CMake and Ninja, but they seemed more difficult to learn and more tedious to work with. GNU Make is a single binary that can be easily …
A lot of existing projects we had been running are based on GNU Make, it does not make sense to move away from that. To build on top of those, GNU Make had been used. A lot of experienced engineers in the team are already familiar with the GNU Make syntax and structure and no …
Codeship is very well suited to teams that have specialized devops members along with other specialized developers. It lets the other developers focus on what they do best, without having to learn another technology stack. This has cut down on a lot of headaches at our company with developers needing to deploy code to various different hosting services across different content management systems. The experience to push code is essentially the same for a developer no matter what the underlying technology is
Makefiles are machine-readable documentation that make your workflow reproducible. If the build process is a very continuous flow of operations within scope, it will do it well and also act as a documentation of all the dependence. For some long-term projects, Make has been used extensively and being maintained to do the job.
In general, it is fair to say the support is sufficient although we do not deal with support directly. There are a lot of forum people chiming in with suggestions or recommendations of particular usage or issues we run into. Since it is open software, patch and fixes will be available from time to time. A lot of information is available in the web now for knowing GNU Make from learning, example, teaching, etc.
Codeship is easier to use than Jenkins because it does not require you to set up your own server, and it provides a large amount of out-of-the-box integrations for version control systems and cloud environments. AWS CodePipeline is native to AWS and cannot deploy applications reliably to other cloud environments such as GCP or Azure.
I'm a full-stack developer that has used various build tools, including Maven, Gradle, and NPM/yarn. For our C projects, I also investigated CMake and Ninja, but they seemed more difficult to learn and more tedious to work with. GNU Make is a single binary that can be easily downloaded, even for Windows under MingW32, is straightforward to learn, and works pretty well despite its age.
We have a few small projects with different developers and Codeship shows everyone clearly, if something work, or if it doesn't.
In one small project with a team of three developers, we have configured two builds and it takes 2-5 minutes for everyone on the team to push changes to an infrastructure handling a little over 3M users.