DevOps teams are crucial for organizations improving engineering efficiency. Core internal customers for DevOps teams are the development teams who rely on development pipelines, which are usually crafted by a DevOps team.
In the field of software engineering, iteration is key to innovation. Your average software engineer will build multiple times a day on their local machine.
At some point, their ideas need to get into the broader team, thus, some sort of external build needs to occur. This is where Continuous Integration (CI) comes into play.
Continuous Integration is automated builds that can be triggered by some sort of event, such as a code check-in, or merge, or on a regular schedule. There are several pieces that can go into a build. The end goal of a build is to be deployed somewhere, and the main goal of Continuous Integration is to build and publish that deployable unit.
For example, you might have a JAVA application that will be deployed into a container orchestrator. In this case, the JAVA distribution (e.g: the JAR/WAR) needs to be built and the packaging (e.g: the Docker Image) needs to be created. If not externalized, specific application properties will need to be injected into the distribution or deployable. Key pillars of Continuous Integration are build, test, and publish.
Running language-dependent build tools, such as in the JAVA ecosystem, such as Maven/Gradle, or in the NodeJS ecosystem, such as NPM. Your build will blend your custom-written code with third-party dependencies.
Unit and artifact-centric tests are prudent to run during Continuous Integration. Since the artifact is not deployed yet, unit tests are great to run in the CI process. If application infrastructure or deployment needs to be tested, for example in a system or integration test, this is better slated for Continuous Delivery (CD). As the artifact/deployable unit is being built or has been built, artifact-centric scans, such as open-source and dependency scans, are great ways to find vulnerabilities and possible license risks.
Once the artifact/deployable unit is created, publishing to an artifact repository/registry is an industry-standard practice. In the JAVA example, you might publish the JAVA artifact to a Maven/artifact repository then the Docker Image to a Docker Registry.
As development teams are starting to be offered in more of a self-service capacity, highly specialized roles, such as build/release engineers, are becoming more of a rarity. DevOps teams, viewed as the ones leading engineering efficiency, would be tasked to replace - or not optimally - become those build engineers.
By leveraging Continuous Integration tools, DevOps teams can provide a platform for development teams to be able to quickly and consistently create artifacts to be release candidates that eventually get deployed.
As builds became more frequent, a common DevOps bottleneck was build infrastructure, especially when dealing with containerization. Homegrown solutions and early Continuous Integration platforms were not built for the scale required in the cloud-native world today.
With the rise of microservices, there is an order of magnitude more builds, and the additional horsepower needed to package your builds add to the overhead. There is certainly a lot of choice of Continuous Integration tools, but there are several prominent platforms.
In the Continuous Integration space here are eight of the top tools to take a look at.
Harness is an industry leader in software delivery with the Harness Platform. Harness CI is an open-source self-service CI solution that is designed to be agnostic and highly performant. Harness recently acquired the Drone open source project, which has over 100 million downloads.
Harness CI has been designed with cloud-native scale in mind by running in container-based solutions, thus alleviating the need for CI-centric dependency management. Harness CI integrates with multiple source code management systems, and leverages a simple and easy to author declarative format to accomplish CI goals. Harness CI is open-source and has both free forever and paid versions.
Jenkins is viewed as the lynchpin in making Continuous Integration mainstream. Jenkins has grown into a family of products and renditions since its 2011 name change. Hailing from the Hudson project, Jenkins focused on JAVA builds to start.
As time progressed, Jenkins X was created to tackle scaling limitations in the platform. Depending on the rendition, there can be the need to support more than one language (e.g: Pipeline DSL ((domain-specific-language)) or scripts written in Groovy). Jenkins is an open-source solution that has vendor support primarily from Cloudbees.
Concourse was built inside Pivotal in 2014 and was designed to automate application and build tasks on the Pivotal Platform. Concourse was open-sourced in 2015, looking to expand beyond the Pivotal Platform. A Concourse Pipeline is like a distributed Makefile. If leveraging a Pivotal Stack, it would be beneficial to look at Concourse.
CircleCI was founded in 2011 and currently has both a SaaS and on-prem solution. It is primarily a SaaS solution that integrates with your source code management solution. CircleCI allows for open-source projects to have a free rendition of CircleCI. As of this time, there is not an open-source version of CircleCI. CircleCI has an extension framework called orbs.
Travis CI was founded in 2011 as a SaaS solution to help open-source projects and was recently acquired by Idera. Similar to CircleCI, Travis CI is integrated with a source code management solution and provides a build service. Travis CI Enterprise provides the ability to install on-prem. As of this time, there is not an open-source version of Travis CI.
In the Atlassian Stack, Bamboo and Bitbucket Pipelines focus on Continuous Integration. Bamboo was the first offering from Atlassian in the CI space, which now has another offering, Bitbucket Pipelines. A few years ago, Bamboo Cloud was discontinued and only made available on-prem. Bitbucket, which was primarily a source code management solution, has stepped into the SaaS CI space with Bitbucket Pipelines, which is focused only on Bitbucket.
TeamCity is a CI platform from JetBrains, which was released in 2006. Pre-dating Jenkins, configuration in TeamCity is written in a Kotlin DSL (domain-specific language). TeamCity is primarily on-prem, with a SaaS version as of this time in beta. TeamCity does not have an open-source version but does have a free version, which is limited to the number of configurations and agents.
When looking for a Continuous Integration tool, at first glance, the tools can be pretty similar if the main goal is to build and publish an artifact. Beyond the direct ability to build and publish an artifact, focusing on both functional and non-functional requirements can help wade through the providers.
As a DevOps engineer, meeting your internal client where they are is important. Most modern CI tools have close integrations with source code management (SCM) solutions. Most modern development projects will be storing build and, presumably, the Continuous Integration configuration in the application/project source code repository. For local development, the ability to interact with the CI tool outside the SCM is important.
In years gone by, Continuous Integration platforms were becoming bottlenecks in the pipeline process. When looking for a CI tool, you will need to make sure the tool has the ability to scale on your infrastructure needs. If your organization has a Kubernetes footprint, the CI tool should be able to scale inside Kubernetes. Having distributed agents/runners are key.
As a software engineer myself, a barrier to self-service is translating existing local build information into Continuous Integration instructions. Ease of use and ease of authoring the needed CI instructions should carry significant weight. If a tool is too complex or is hard to stand up, the DevOps team will be handholding the development team every time there is a new service or changes needed.
Lastly, looking at how robust the Continuous Integration tool’s platform is should be paramount. In technology, the only constant is change. As new languages, packaging, repositories, and paradigms that fall under Continuous Integration continue to evolve, how well does the CI platform adapt to those changes? Harness CI is purpose-built with change in mind.
The Harness Platform provides industry-leading capabilities around software delivery. An important part of software delivery is actually building what needs to be deployed and orchestrating the tests that make the build successful.
In the Continuous Integration world, there are certainly a lot of choices. Harness Continuous Integration is designed with simplicity, scale, and self-service in mind for technologies of today and tomorrow.
Want to learn more about CI tools? Get our CI/CD Buyer's Guide for more in-depth comparisons of a bounty of CI tools.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.