Continuous Integration, Continuous Delivery, Continuous Deployment, CI/CD, DevOps, cloud native, and Site Reliability Engineering. The development world is full of jargon that can be difficult to understand at first glance. In this article, we'll explain what CI/CD is, the differences between these concepts, what a CI/CD pipeline looks like, and which CI/CD tools are popular today.
CI/CD is a method for frequently delivering applications to (end) customers with almost all steps automated. CI/CD is often seen as a solution for large development teams wanting to avoid what's known as "integration hell."
This integration hell emerges when developers and system administrators work separately on the development and delivery of an application without coordinated processes.
The CI in CI/CD almost always stands for Continuous Integration. At the same time, CD can mean either Continuous Delivery or Continuous Deployment. The content of these two terms is sometimes used interchangeably, which can be confusing.
The ultimate (technical) goal of CI/CD is to get code into a stable, high-performing production environment faster and with fewer errors. This increases developer productivity and gives an organization an edge over competitors.
Due to the high degree of automation throughout an application's entire lifecycle, CI/CD becomes essential for organizations working with DevOps methodologies or using a Site Reliability Engineering (SRE) approach. CI/CD is also used by teams developing with the help of cloud native technology such as Docker containers or Kubernetes.
Continuous Integration (CI) enables developers to contribute code and collaborate quickly through a shared codebase. Without CI, collaboration between developers would involve many manual tasks and coordination when new code is updated or merged.
Continuous integration is based on several best practices from the software development world, including automated testing, version control, build automation, and automated deployments. There are tools for each discipline, although some CI tools combine many of these functions. You can read more about popular CI tools in the section on popular CI/CD tools.
The CD in CI/CD refers to Continuous Delivery or Continuous Deployment. The two terms are often used interchangeably, but they are different.
In both cases, they are responsible for further code delivery in the CI/CD pipeline.
Continuous Delivery typically means that a developer has made changes to an application, tested these changes for bugs, and uploaded them to a code repository (such as GitLab or GitHub). From this location, the code is ready to enter a production environment, but the actual implementation of the code is often still a manual action performed by a system expert.
Continuous Delivery aims to deliver code ready for the production environment as quickly and error-free as possible.
With Continuous Deployment, no system expert is involved anymore because the code is automatically implemented in the production environment as soon as the developer "releases" the code. Automated tests and checks are first performed to ensure nothing breaks during deployment.
The advantage of Continuous Deployment is that the code goes directly to the end product (the software), allowing developers to achieve tremendous speed gains. This enables the organization to deliver software faster than competitors, for example.
This image best summarizes the differences between Continuous Integration, Continuous Delivery, and Continuous Deployment.
CI/CD is often a linear process, which is why people often talk about a CI/CD pipeline. The developer's code must first pass through all automated integration tests, then all delivery tests, and finally, the deployment tests.
In modern application development, multiple developers often work on an application simultaneously. Every so often, the code needs to be added to the production environment (also called "merging"). This can be a rather cumbersome and manual process because problems can arise with each change.
For example, issues might occur if developers work in their own local IDE instead of the IDE agreed upon within the team. Problems can also arise with version control.
Applying CI eliminates the need for special "merge days" because committing code can happen frequently or continuously. All changes the developer has made are automatically checked to ensure the new code doesn't break the application. If an error is detected, it's often easier to resolve because CI-software clearly shows where the error is located. This allows even small pieces of code to be added. Teams can also develop microservices more quickly.
With Continuous Delivery, the delivered code in the repository is checked again and verified for additional production environment considerations. Think about the impact of the new code on performance and stability in the production environment. Just like with CI, various tests are performed, and errors are automatically identified.
Continuous Deployment is the final maturity phase of CI/CD. The automated tests must be extremely well-designed since the code goes directly to the production environment without human intervention. In theory, a developer can see changes in the production environment within minutes. In practice, this is still quite rare. It might happen at large companies like Google, as they often have the resources and expertise to realize this on a large scale.
There are several popular tools for development teams wanting to start with CI/CD. Some of these tools focus only on CI, others only on CD (both delivery and deployment). Here are a few highlights:
Jenkins is a popular Java-based open-source continuous integration (CI) server that allows for quick and automatic code addition to software such as web applications. For many, it's the de facto standard for CI. An alternative to Jenkins is CircleCI.
You might know GitLab as a code repository, but it also has a built-in tool for CI/CD. The tool is quite extensive, and fortunately, the documentation is just as comprehensive.
Although the popular container orchestration platform Kubernetes is not a CI/CD tool, it integrates particularly well with many CI/CD workflows. Therefore, many cloud native development teams dealing with large numbers of workloads use Kubernetes.
A relatively new player is Azure Pipelines. This software is part of the Azure DevOps stack and can automate both CI and CD components. It's especially suitable for developers wanting to bring cloud native applications to Azure.
In practice, CI/CD often proves to be a particularly complex game. The automated tests must always be written by one or more people. It takes a lot of time to think about how to automate something as simply as possible with minimal error margins.
The company and developers often desire speed, but when writing tests, the security and stability of a production environment must also be considered. For this reason, it's advisable to make application delivery a shared responsibility between developers and system experts.
Both IT disciplines view the entire CI/CD pipeline through their own lenses. By working together using a DevOps or SRE methodology, you combine each other's strengths, allowing the organization to take serious steps forward.
Don't have system specialists on staff and want to brainstorm how your code can be delivered faster and with fewer errors using a CI/CD pipeline?
