Today, Continuous Integration and Continuous Delivery (from now CI/CD) are two fundamental practices to automate software development and delivery. Indeed, when adopting DevOps tools and practices, the CI/CD pipelines help developers to automate testing, security checks in addition to builds and deployments.
However, there are plenty of tools that can implement these mechanisms in a more or less flexible way and each of them has some capabilities that could make it more or less feasible for a specific use case.
Let’s dive into some of the main and most used tools which we have worked with by analyzing some of their strengths and weaknesses.
Jenkins
Jenkins was created in 2004 by Kohsuke Kawaguchi. Originally called Hudson, it was renamed after a name conflict with Oracle.
It’s easily extensible since it supports a [master-slave architecture](https://en.wikipedia.org/wiki/Master/slave_(technology)) that allow to create new “worker” nodes which after the installation of an agent, allow to execute CI/CD pipelines onto their computing resources.
As of today, it’s one of the most popular tools to implement CI/CD pipelines. This is because in addition to having a very active community and being open-source, it has among its advantages that of having great flexibility. In fact, thanks to its plugin system, it allows the integration of a great number of technologies. Moreover, its Domain-specific Language (DSL) based on Groovy, allows to code CI/CD pipeline in a flexible way adapting to every need.
But pay attention! Jenkins’ great flexibility could be a double-edged sword. In fact, leveraging too much on the integrations and writing complex pipeline code could make it difficult to use. Plus, you may run into scalability issues due to the excess of resources needed for the pipelines’ correct execution.
GitLab
You may know GitLab as one of the most widely used software development platforms. Basically, GitLab it’s an open source product available for free but has also some commercial plans with additional features and support.
In the last few years, GitLab implemented an integrated CI/CD system. This represents a huge advantage for those that are already using the platform to store Git repositories, avoiding to install an additional tool (like Jenkins) and having a full integration with the other GitLab tools such as those used for planning or ticketing.
The system requires the installation of a so called “Runner” released by GitLab, that allows to execute CI/CD pipelines inide physical machines, virtual machines or even inside containers. The language used to code the CI/CD pipelines is YAML and follows a precise schema defined by GitLab described in the documentation. Anyway, the actual commands are coded in the language supported by the system shell running the Runner (batch/powershell for Windows, bash/sh for Linux).
However, also GitLab has some weaknesses. For example, some advanced features like AutoDevOps, high availability, security enhancements and integrations with tools like Jira, Slack, Kubernetes, are only available with the commercial version.
GitHub
Even the most used software development platform has developed its own CI/CD system, called GitHub Actions. Also in this case, the perfect integration of the CI/CD system with the repository management is a strong point.
One of the GitHub Actions capabilities is the possibility to compose the pipelines (here called “workflows”) with smaller blocks called Actions (hence the name). These Actions are available in a marketplace, allowing to implement entire workflows without the need to code pipeline steps like in Jenkins or GitLab. Many actions are verified directly by GitHub and are very well documented.
Anyway, you should be aware of the Actions you are using. Some of them come from third-parties and could potentially execute malicious code. Moreover, you have to understand if a specific Actions actually reponds to your needs. If not, you could face the need to rewrite some parts of the workflow or fork the Action and customize it accordingly.
Other tools
Obviously the ecosystem of tools available to create CI/CD pipelines is very wide. Over the ones we analyzed, there are some other that deserve to be mentioned.
- Travis CI
- Circle CI
- Atlassian Bamboo, integrated with BitBucket and the Atlassian Suite ()
- TeamCity by JetBrains
- Tekton, the Kubernetes-native CI/CD
- and the more recent tools that follow the GitOps practices like ArgoCD and Flux.
Conclusion
Ultimately, when it comes to choosing the right tool to implement CI/CD pipelines, it’s necessary to understand your own needs and search accurately for the indispensable features in the various tools. Maybe, more than one tool will be able to respond to you needs, so you will need to evaluate also aspects like the usage experience, which includes ease of installation and maintenance, the language used to code the pipelines and the eventual presence of documentation, community support and commercial support.