What is a CI/CD pipeline?

In simplest terms, a Continuous Integration / Continuous Delivery (CI/CD) pipeline is simply a predefined series of steps that must be performed in order to deliver a new version of software for final deployment to production. By explicitly defining the steps that software development must proceed through, software delivery speed and reliability can be greatly improved.  It should not be surprising that as CI/CD process bridges the Dev and Ops sides of software delivery, that it is foundational to standard DevOps (and SRE) approaches.

While automation is not explicitly assumed by a CI/CD process, the greatest value of CI/CD pipelines is in accelerating development processes. Automating systems monitoring and testing allows rapid feedback on software state and supports rapid intervention to correct issues in the development and deployment stages. At the extreme of CI/CD automation, the “CD” actually is continuous deployment (sometimes called continuous release) where software updates that pass all required steps in a pipeline are pushed directly to production without human intervention. 

What makes up a CI/CD pipeline?

A CI/CD pipeline is typically divided into a set of discrete stages. These are generally a set of tasks that have a related function. Here are a few common pipeline stages:

  • Build – The application is compiled.
  • Test – The code is tested.  This can (and really should) include unit and integration tests. (Note that this stage can happen at the CI and CD parts of the overall pipeline.)
  • Release – The stage where the application or artifact is delivered to the repository.
  • Deploy – The artifact is deployed to production. In continuous delivery this requires manual approval, in continuous deployment, this stage is automated.

This list of pipeline stages are common, but what your pipeline will look like will be determined by the tooling and requirements of your team. There are some applications, like Tekton, Jenkins, and Travis CI that can be used to serve both the CI and CD aspects of the overall pipeline.  There are also applications like Spinnaker and Harness that focus on the CD side of things and it is not unusual to see different CI and CD solutions being used together.

Why CI/CD pipelines matter

If you are considering implementing CI/CD, we can probably agree your end goal is to successfully deliver ever improving software to your customers. Conversely, you are probably not hoping to spend time on the repetitive infrastructure that supports that goal.  The CI/CD pipeline, whether supported by a single piece of software or a collection, is intended to define a reliable and repeatable development and deployment process that keeps the focus on improving your application.  

This is not to say that your pipeline will not change once it has been developed. As initially noted at the beginning of this article, what your CI/CD pipeline looks like will depend on the needs of your team.  If you are just starting out, you may only have a CI pipeline in place.  As you grow you may add continuous delivery and then continuous deployment to the overall pipeline.  You may further add functions along the way. For example, the Jenkins ecosystem includes over 1500 plugins that integrate into the CI/CD process. Much like the software that is the focus of your work, your CI/CD pipeline can continue to improve, eliminating toil and accelerating your time to value.