Continuous integration and continuous delivery (CI/CD) is a set of practices for getting software changes from a developer to users quickly and safely. Continuous integration (CI) means developers merge their changes into a shared codebase often, at least daily in many teams, and each merge triggers an automated build and test run. Continuous delivery (CD) extends that automation so tested changes are packaged and kept ready to release at any time; in continuous deployment, a variant also abbreviated CD, they go to production automatically once they pass. Which meaning of CD people intend varies, so it is worth asking.
At a glance
- CI: frequent merges, each automatically built and tested.
- CD: an automated pipeline that prepares tested changes for release, or, in continuous deployment, releases them.
- The pipeline is also where security scanning, quality checks and approvals can run.
- It is a core practice of DevOps, and supports Agile teams releasing small increments.
- Done well, releases tend to become smaller, more frequent and easier to roll back.
What problem it solves
When teams merge code rarely and release in big batches, each release becomes an event. Changes from many people collide, problems take days to untangle, and testing is squeezed at the end. Releases are risky, so they happen less often, which makes each one bigger and riskier still. Fixes, including security patches, wait for the next release window.
CI/CD breaks that cycle by making change small and routine. Merging often means conflicts are small and found quickly. Automated tests on each change catch many errors within minutes, while the developer still remembers the code. A repeatable pipeline means releasing doesn’t depend on one person’s manual steps. For the business, the result is usually faster delivery of fixes and features, and fewer surprises on release day, though how much improves depends on the quality of the tests and the pipeline.
How it works
Source control. The code lives in a shared repository. Developers work on small changes and merge them back frequently, often after a peer review.
Build and test. Each merge triggers the pipeline: compile or package the application, run unit tests, then broader integration and functional tests.
Security and quality checks. Many pipelines run static application security testing (SAST), software composition analysis (SCA) and other checks, and can stop a change that fails policy. Building security into the pipeline is central to DevSecOps.
Packaging. Passing changes are packaged into a release artifact, often a container image, and stored. Environments are increasingly defined with infrastructure as code (IaC) so they are consistent from test to production.
Release. The artifact is deployed to test and staging environments and then to production, automatically or after an approval. Techniques such as gradual rollouts and feature flags limit how many users see a change at first, and monitoring watches for problems so a release can be rolled back.
Evidence. Pipelines log what changed, who approved it and what passed, which can support IT change management and audits.
When it matters for buyers
- When buying SaaS or packaged software. A vendor’s CI/CD maturity affects how quickly it can ship fixes, including security patches, and how often its updates cause problems. Ask how changes are tested and rolled back.
- When outsourcing development. Make the pipeline part of the deliverable. The statement of work can require that code lives in your repository, builds and tests run automatically, and you receive the pipeline configuration at handover.
- When a managed or cloud provider changes your environment. Ask whether changes go through an automated, tested pipeline or manual steps.
- When reliability matters. Frequent, small releases work best with good monitoring; site reliability engineering (SRE) teams often set release pace against reliability targets. Our application performance monitoring and observability overview covers the tools that watch releases in production.
Questions to ask vendors
- How often do you release, and is that continuous delivery or continuous deployment?
- Which tests and security scans run on each change, and what stops a release?
- How do you roll back a bad release, and how long does it take?
- How do you notify customers of changes, and can we delay or opt out of some?
- For outsourced work: will the code, pipeline and its configuration live in our accounts?
- How do pipeline records support our change management and audit needs?
How it differs from DevOps
DevOps is the broader culture and set of practices for bringing development and operations together, sharing responsibility for how software is built, released and run. CI/CD is one specific practice within it: the automated route from a code change to a release. An organization can have a CI/CD pipeline without working in a DevOps way, for example if operations still receives releases over the wall with no shared responsibility. And DevOps includes more than CI/CD, such as monitoring, incident response and infrastructure as code.