What CI/CD means
CI/CD is a set of practices for moving code changes to users in small, automated steps. CI, continuous integration, means everyone merges small changes into a shared main branch at least daily, and every merge is built and tested automatically. CD stands for continuous delivery or continuous deployment, which differ only in the final step to production.
The three practices build on each other. Delivery assumes integration is already in place, and deployment assumes delivery is.
- Continuous integration ends with a tested build: every change is merged into the main branch often, then built and tested automatically.
- Continuous delivery goes further. Each change that passes is packaged and deployed to a production-like environment, and a person decides when it reaches production.
- Continuous deployment removes that last manual step, so every change that passes the automated checks goes to production.
Continuous integration: merge small changes every day
The integration in continuous integration is combining your changes with everyone else's. The longer a branch lives apart from the main branch, the further the two drift and the harder that merge becomes. CI keeps the gap small by merging at least once a day, usually through short-lived branches or pull requests.
Each push or pull request triggers an automated build and test run. When the main branch breaks, fixing it comes before any new work, because every developer is building on top of it.
A CI server alone does not mean a team practices CI. If feature branches live for weeks, the tests still run automatically, but the real integration happens late, in one large and risky merge.
Continuous delivery: a main branch you can release at any time
Continuous delivery means the main branch is always in a releasable state. Every change that passes CI goes through the same automated pipeline: it is packaged, deployed to a staging environment that resembles production, and checked there.
Releasing to production then becomes a business decision. Someone approves it or picks a time, and the pipeline runs the same deployment steps it has already run many times.
On top of CI, continuous delivery needs:
- Deployment that is fully scripted, so staging and production are deployed the same way.
- Tests you trust enough to release on, including some that run against the deployed system.
- A way to merge unfinished work without exposing it, usually a feature flag that keeps the new code switched off.
Continuous deployment: every passing change goes live
With continuous deployment, nobody approves individual releases. A change that passes every automated check is deployed to production as soon as the pipeline finishes, without anyone pressing a button.
That makes the automated checks the only gate, so they have to catch what a person reviewing the release would have caught. Teams that deploy this way watch error rates after each deploy and can roll back in one step. They also use feature flags, so deploying code and releasing a feature are separate decisions.
Continuous delivery is the usual stopping point when a release needs a step outside the team's control, such as an app store review or a customer's maintenance window.
Why small, frequent changes reduce risk
Deploying more often sounds riskier, but each deploy carries less change. A release with three commits is quick to review, and if it breaks something, there are three suspects instead of three hundred.
Small changes also fail early. Problems surface within hours of the code being written, while the author still remembers it, and the fix or revert is small too.
The deployment process improves with use. Steps that run every day stay scripted and tested, while a process that runs once a quarter collects manual steps that nobody remembers how to do.
Where to start with CI/CD
Most teams adopt the practices in this order, because each depends on the one before it.
- Keep all code in version control with one main branch, and merge to it at least daily.
- Run the build and the fastest tests on every push or pull request, and block merges that fail.
- Keep the test run short enough that people wait for the result, ideally a few minutes.
- Script the deployment so that one command, or one pipeline run, can deploy any version.
- Deploy every passing change to staging automatically, then decide whether production releases stay manual or become automatic.