Continuous delivery is a vital element of the software pipeline, defining how quickly a project releases changes and fixes bugs. While there are many paid, closed source tools from vendors like AWS and Azure, for example, some open source continuous delivery tools give paid tools a run for their money.
But before we dive into any specific open source tools, let's clear up some common misunderstandings about what the term open source actually means.
What is an open source tool?
Open source indicates that the tool's source code is made freely available, either for viewing or editing, depending on the tool. For example, some open source licenses prohibit modifications, but most licenses allow users to copy the code for modification and redistribution.
The most basic definition of open source is self-explanatory: The source code is openly available. Be wary of tools that are labeled as open source but don't make their source code publicly available. Many tools that are free, but don't share their source code, are often mistakenly referred to as open source. Just because a tool is free does not mean it is also open source.
The tools in this list are all related closely and can be generally substituted for each other in functionality. They are continuous delivery tools specifically in how they provide software, a running cloud server or some combination of the two to enable users to build, test and deploy their application via automation.
Drone, written in the language Go, is a self-hosted tool. This means the user is responsible for the server where the software runs. In general, self-hosted tools are more flexible and cheaper to use. Because users control the server where Drone runs, they can use a cloud resource from Azure, AWS or Google Cloud, or run Drone on a physical machine. This is cheaper for the user at the expense of the work that goes into server maintenance.
Drone runs as a Docker container, which makes it easy to deploy onto any modern server. Combining Drone with Kubernetes enables Drone to scale and handle many builds at once, enabling quicker builds for an organization that has many projects building in parallel.
GoCD is another self-hosted option, written in a mix of Java and JRuby on Rails. GoCD is easy to use, offering a convenient, user-friendly wizard to create pipelines to build and deploy applications. GoCD uses a plugin feature to integrate with different version control providers such as GitHub or cloud infrastructure providers like Azure and AWS.
GitLab CI is a popular option from the GitLab version control software project, offered as both self-hosted or software as a service (SaaS).
With the SaaS option, GitLab provides the server where the continuous delivery pipelines run. There is a cost associated with using a SaaS tool, but for a project, the monetary tradeoff might be preferred over the expense of server maintenance.
Pipeline as code in Jenkins is essentially an Apache Groovy script that enables users to define Jenkins jobs programmatically. Using a language like Groovy to define build pipelines sets Jenkins apart from other continuous delivery tools that use YAML or other more configuration-focused languages.
While YAML is human readable and has a minimal syntax, a full programming language like Groovy opens opportunities for more complex data structures and program flow.
Less popular than the other options listed, but still a reliable choice, is Travis CI. Travis CI is offered as a SaaS and integrates with all major version control providers like GitHub, GitLab and Bitbucket. There are free and paid tiers, with the paid Travis CI providing more concurrent builds, which allows users to run builds for many projects at one time. Travis CI is written in Ruby and uses a YAML configuration file to define build pipelines.
In general, these tools are functionally equivalent. They automate application pipelines from build and testing to deployment. Trial different options and see which works best for your organization. Every tool listed above offers a free tier of use, and some, like Jenkins and GoCD, are free. An organization might find that it prefers to host its own continuous delivery server, or it might be more natural for the project's team members to use a SaaS tool. The most important outcome is the value the tool provides, and only by experience can that value be assessed.