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.
