CI/CD (CI/CD)
CI/CD is a set of practices for integrating, testing and preparing software changes for release through repeatable pipelines. Continuous integration checks changes frequently. Continuous delivery keeps passing changes ready for an approved release, while continuous deployment releases them automatically. Teams configure the checks and controls that suit their application.
Also known as: continuous integration, continuous delivery, continuous deployment, build pipeline
Last reviewed
Why CI/CD matters
A manual release is a sequence of steps somebody remembers. It works until the person is on holiday, until a step is skipped under time pressure, or until the environment has drifted since the last time anyone ran it. Because manual releases are risky, teams do them rarely, and because they do them rarely, each one carries more change and is riskier still.
CI/CD breaks that loop by making the release boring. Every change goes through the same automated path, so routine release work becomes more repeatable, and each release contains less to go wrong. When something does break, the change that caused it is small and recent enough to identify.
The second benefit is evidence. A pipeline produces a record of what was built, what was tested and what was deployed, which matters in any regulated or audited environment.
How CI/CD works
A change pushed to version control triggers the pipeline. A typical sequence is:
- Build the application from source in a clean environment
- Run automated tests — unit, integration and often end-to-end
- Run quality gates such as linting, type checking and security scanning
- Produce a versioned artefact, commonly a container image
- Deploy to staging automatically and run checks against it
- Release to production, either on approval (continuous delivery) or automatically (continuous deployment)
- Apply database migrations and verify the deployment actually took effect
Required checks should block promotion when they fail. Configure permissions and release controls so bypasses are restricted and recorded; automation alone does not enforce that policy.
Continuous delivery vs continuous deployment
The CD half has two readings and they differ by one decision. Continuous delivery means every change that passes the pipeline is ready to release, and a human chooses when. Continuous deployment means every change that passes is released automatically with no approval step.
Continuous delivery suits teams that need an approval or coordinated release window. Continuous deployment suits products with strong automated test coverage and a fast rollback path.
When you need it
You need CI/CD as soon as more than one person changes the code, or as soon as the software is live in front of users. The warning signs are familiar: releases scheduled for evenings, a deployment checklist in a document, and a staging environment that no longer matches production. It is a core DevOps practice and can support containerised deployments on AWS.
Further reading
AWS: continuous delivery explains the underlying approach.
CI/CD: common questions
CI is continuous integration: frequently integrating changes and checking them through automated builds and tests. CD means continuous delivery, which keeps changes ready for release, or continuous deployment, which releases passing changes automatically.
Continuous delivery allows an approval before production release. Continuous deployment automates that final step when checks pass. Choose according to your release risk, test coverage, operational controls and customer needs.
A small, frequently changed application can benefit from a simple pipeline. Prioritise repeatable builds, useful tests, deployment checks and a recovery plan. The required controls should match the consequences of a failed release.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.