Two ideas that fit together
“CI/CD” is shorthand for two related practices. Continuous integration means that every time someone changes the shared code, the project is automatically built and tested. Continuous delivery means that the software is always kept in a state where it could be released, and that the steps to release it are automated.
Both exist to solve the same underlying problem. When people work separately for a long time and combine their work at the end, the pieces often do not fit. Finding and fixing those conflicts late is slow and stressful. Combining small changes often, and checking each one automatically, turns a large unpredictable problem into many small ones.
Continuous integration
In a team using continuous integration, developers share their changes with a common repository frequently, often several times a day. The repository relies on version control, which records every change and lets people work on separate copies and merge them.
Each time a change is shared, an automated system picks it up and runs a series of checks. These typically include:
- Building. Compile or package the software to confirm it can be produced at all.
- Automated tests. Run a collection of tests that check that existing behavior still works.
- Code checks. Look for style problems and common mistakes.
- Security checks. Scan dependencies and code for known issues, in the same spirit as vulnerability scanning of running systems.
If any step fails, the team is told quickly, while the change is still fresh in the author’s mind. The usual convention is that a broken build is fixed first, before new work continues.
The value depends heavily on the tests. A pipeline that runs weak tests gives false comfort. A suite that is thorough but extremely slow gets ignored. Teams generally aim for fast checks on every change, with slower, broader checks run less often.
Continuous delivery
Continuous integration ends with software that has passed its checks. Continuous delivery carries on from there. The same pipeline prepares a release package, deploys it to a test or staging environment, runs further checks and leaves it ready to go live.
In many setups, the final step to production is a deliberate human decision, such as pressing a button after approval. The key point is that the step is easy, repeatable and low in drama, because everything before it has been rehearsed many times.
You will also see continuous deployment, in which every change that passes all the checks goes to production automatically with no manual gate. This suits some teams and products. It is not suitable everywhere, particularly where a mistake would be costly or where regulations require sign-off. Delivery and deployment are different choices, and an organization can sensibly adopt one without the other.
What a pipeline looks like
A pipeline is a sequence of stages that a change passes through, written down as a file and stored with the code. A typical one has these stages:
- Source. A change is shared with the repository and triggers the pipeline.
- Build. The software is compiled or packaged into something that can be run. Often this produces a single artifact that moves unchanged through every later stage, so that what was tested is exactly what is released.
- Test. Automated tests run at several levels, from checking small pieces of logic to checking that the parts work together.
- Staging. The artifact is deployed to an environment that resembles production, where further checks run.
- Release. The artifact is deployed to production, either automatically or after approval.
- Verify. Monitoring confirms the release is healthy.
Because the pipeline definition is a file, it can be reviewed and changed like any other code, which links to the idea of infrastructure as code.
Packaging software into software containers is a common way to make the build artifact behave the same in every environment, though it is not required.
Making releases safer
Frequent releases can sound risky. In practice, several techniques make them safer.
- Small changes. Fewer changes per release means less to go wrong and a smaller search area when something does.
- Staged rollouts. Release to a small share of users first, watch the results, then widen the release.
- Feature switches. Ship new code in a switched-off state and turn it on separately from the deployment, so that turning it off again is quick.
- Fast rollback. Keep the previous version available so that you can return to it.
- Monitoring after release. Watch error rates and responsiveness as a release goes out, supported by good system monitoring and alerts.
Databases deserve special attention. A change to the structure of a database cannot always be undone as easily as a change to code, so teams plan these changes carefully and often split them into several compatible steps.
Benefits and limits
Teams that adopt these practices commonly report faster feedback, less release-day stress and fewer surprises, although results depend on the quality of the tests and the discipline of the team.
There are costs. A pipeline needs to be built and maintained. Tests need to be written and kept reliable; tests that fail randomly teach people to ignore failures. The pipeline itself becomes critical infrastructure, and it often holds credentials that can reach production, so access to it should follow least privilege and be reviewed carefully.
Getting started
You do not need a full pipeline on day one. Many teams begin by running automated tests on every shared change. Next they automate the build, then automate deployment to a test environment, and only later automate production releases. Each step removes a manual task and increases confidence in the next.
Whatever the tooling, the habits matter more: keep changes small, keep the main version working, fix failures quickly and treat the release process as something to improve continuously.