With continuous delivery, every change made to the system can be released, and any version can be released at any time. Continuous integration is the natural extension of continuous delivery. Continual delivery provides quick feedback on what users care about and aims to make releases boring.
The continuous integration and continuous delivery (CI/CD) method are transforming DevOps. Even if each step of the software development lifecycle can be carried out manually, CI/CD automates the stages in software development and deployment.
Continuous Integration (CI)
Continuous integration is the process of merging code (updates or existing features) with an existing codebase (software tool or product, for example). CI is a development practice where developers merge code in a central repository several times daily.
In CI, each line of code added to the codebase triggers a sequence in a CI/CD pipeline, generating feedback for developers. This process allows improvements to be made quickly and easily.
Continuous Delivery (CD)
CD is an attempt to speed up and automate deployments. An operator can push out multiple deployments in a week across numerous services and know the exact condition of the applications and infrastructure in the course of the deployments.
“Continuous delivery is the natural extension of continuous integration, an approach in which teams ensure that every change to the system is releasable, and release any version with the push of a button. Continuous delivery aims to make releases boring so that we can deliver frequently and get quick feedback on what users care about.” — Thought Works
How Platform Engineering Helps Manage Innovation Responsibly
The Focus of a CI/CD Pipeline
To run a CI/CD pipeline successfully, organizations should outline goals that guide developers’ approaches and processes. While each pipeline is unique, it should reflect some overarching goals.
Here are some results that should be the focus of the pipeline:
Quick Fixes and Improvements in Subsequent Updates
CI/CD automation automatically allows code changes to reflect in end users’ software. CI/CD pipelines should prioritize quick fixes and improvements to existing code to improve software quality and user experience.
Push Button Deployments
Continuous delivery requires a “state” machine, which is not provided by CI tools. CD tools, such as Spinnaker, can take an environment from one state to the next until it makes it to production. The machine will move the environment, such as Docker containers, through to production in an automated fashion. It will even be able to do rollbacks, canary deployments, and scaling instances.
This process allows for the agile, push-button, automated deployments that an ideal CD mindset drives towards. Such pipelines are at the core of CD capabilities because they orchestrate a repeatable deployment over stages.
Fast and Frequent Software Releases
One of the higher-level achievements in a DevOps transformation is continuous delivery. Focusing on software releases in a CI/CD pipeline is a cultural shift for companies because it involves organizational change, too. DevOps transformation means building cross-functional teams with common goals, aligning the organization around the architecture, and creating a culture of continuous improvement.
Three Ways CI/CD Adoption Can Benefit Your DevOps Team
The Structure of an Effective CI/CD Workflow
The process for achieving CI/CD goals has been broken down into six stages. The goal is to ensure that new and runnable code is fit for use before it’s sent out to end users.
Most unique and effective pipelines mirror the following structure:
Each new pipeline run is triggered by a change in the source code repository. An update or variation to the existing code — such as automated workflows or results from a previous pipeline run — begins the CI/CD process.
In this stage, runnable instances of code that could potentially be deployed to end-users are created. This is done through a combination of source code and its dependencies. Code not passing this stage indicates a problem with the project’s configuration and should receive immediate attention.
Automated tests are run on the code to determine its accuracy. These tests, created by software developers, are required to meet certain standards. Multiple tests at this stage would detect bugs or other problems developers do not foresee. The test could take minutes or several hours, depending on its complexity. Code that does not successfully pass this test stage instantly notifies the development team that adjustments must be made. After the code is tested and considered runnable, it’s delivered to the repository.
Deploy. Once the code passes all predefined tests, the runnable code in the repository is deployed into different environments, such as a staging environment for the internal team and a production environment for end-users.