The Continuous Integration space is as busy as ever in 2023. There are a lot of great tools, but picking between them is hard. I am a big fan of Continuous Integration tools, and if you are not using any, now is the time to start.
The challenge is knowing which tool to use. There are many options so I will break down my top choices and when I would use them. I do not pretend to know all the tools out there, there are too many, but here are the best ones I personally have used.
Github Actions
If you use Github, you should use Github actions. It will connect to your code and uses Docker containers to run your code. It’s generally fast and if you have an open-source project, it’s free. What’s more, using the Github Marketplace, you can get ready-made integrations for lots of platforms.
Github Actions are coupled to events on Github like a code push, a new issue being created or a release. They also work well with other Github services like Github Packages if you are storing build artefacts there. It also supports a range of environments such as Windows, Mac or Linux as well as support for complex Matrix builds and other branches.
When not to use Gihub Actions
The only major limitation of Github Actions is when you need to host your code on Github. If your code is hosted somewhere else, you will have difficulty getting Github Actions to work for you. It is possible if you start using the API to create trigger events like a pull request, but there are other tools you can use.
AWS Code Build
AWS Code Build is good if you are working in the AWS ecosystem. There are integrations for various code repositories, including Github and AWS’ own Code Repositoy.
The nice thing about Code Build is that you can assign IAM roles to your runners. That means you use AWS services without needing to give out keys to other services. It also means you can manage everything with your Terraform code or other Infrastructure as Code tools.
I’m picking on AWS here because I know it well. Google Cloud Build and Azure DevOps are both excellent if you are working on those platforms. All these tools use containers to run the builds and integrate well into the ecosystem of those platforms.
When not to use AWS Cloud Build
If this is your only AWS service, then I wouldn’t use it. To make Cloud Build work, you are going to need to think about IAM roles, secrets, and build logs. If you are already working in AWS, then that will all be easy but if you are not deploying to AWS then there are similar tools to use.
Circle CI
Circle CI is one of the few dedicated Continuous Integration platforms on this list. They has been in operation for over ten years and have built a powerful platform.
The nice thing about Circle CI is that they are only a CI platform. Github, AWS, GCP and others are all technology providers that include a CI service but it is not their core business. Circle CI is only doing CI so it is in their interest to make it as good as possible.
It has good integration with Github, Gitlab, Bitbucket. The configuration is all in a yaml file and the Orb selection allows for out-of-the-box integration with a range of tools.
When not to use Circle CI
There are not really many times that you would not want to use Circle CI if you are happy to use a SaaS provider. The only consideration is that it is another service, another cost and another account to manage. If you are using only AWS or can do everything with Github Actions, then will Circle CI add enough to justify the added complexity?
The place where Circle CI will shine is for projects with lots of integrations. If your code is deployed to multiple clouds and platforms and has to integrate with lots of third-party tools, then Circle CI provides a powerful neutral ground to manage everything.
Jenkins
We can’t talk about CI without talking about Jenkins. There are certainly developers who dislike Jenkins, but it remains a free and popular choice for CI. The good thing about Jenkins is that you can download it and just run it on any server with Java. It can also live inside your network, and you can control all the data.
For a lot of high-security organisations like banks, the Government and big companies having something they control is a massive issue. If you are using an internal Git repository and test servers, you might find that a cloud-based service is not an option.
When not to use Jenkins
Jenkins does have its issues, but it remains a stable tool with a large user base, so it’s easy to hire the skills you need. The main reason not to use Jenkins is if you install it in the cloud, then stop and think about what the cloud provider can offer.
Gitlab CI
Gitlab offers it’s own built-in CI platform. Like several others on this list, it uses a yaml-based pipeline and Docker images to run build steps. It’s configuration is simple and well documented, so it has become popular for organisations that want to host their own CI and use Gitlab to store their code.
Like several others on this list, it all comes down to which Git provider you use. Gitlab CI is good, but only if you store your code in Gitlab. You can use it without keeping your code there, but there is no good reason to do that.
When not to use Gitlab CI
There are two main reasons you would not want to use Gitlab CI. Assuming you are running Gitlab inside your network, then you must be considering it because you cannot use a SaaS solution like Github.
Which Continuous Integration Provider should you use?
Honestly, it depends on the circumstances. Here is a flowchart to help you pick.
The fact that you are debating providers is a good thing. It shows you care about quality and automation, so that’s a great start.
Picking a tool depends on where your code is, where you will deploy and how much money you have to spend. Countless other providers are out there who can offer specialist services if that’s what you need.