CI/CD stands for continuous integration and continuous delivery (or deployment). It is a way of automating the steps that take a code change from a developer's computer to a running website or app. Instead of building, checking and releasing by hand each time, a pipeline runs the same agreed steps, in the same order, for every change.
What CI and CD each mean
- Continuous integration (CI): developers merge their changes into a shared codebase often, and each change automatically triggers a build and a set of checks, such as automated tests. Problems show up soon after a change is made, while it is still easy to trace.
- Continuous delivery (CD): once the checks pass, the change is packaged and prepared so that it can be released to a test or live environment. A person usually still approves the final release.
- Continuous deployment: a further step in which a change that passes every check goes live automatically, with no manual approval. Not every team or business wants this.
"CD" is used for both delivery and deployment, so it is worth asking which one a vendor means.
What a typical pipeline does
Pipelines differ from project to project. Common steps include:
- Build: turn the source code into a version that can run.
- Automated tests: run tests on small pieces of logic and on larger flows. Repeating earlier checks after every change is the idea behind regression testing.
- Code and dependency checks: apply formatting rules and look for known problems in the libraries the project uses, depending on how the project is set up.
- Deploy to staging: place the build in a staging environment for further review.
- Release to production: publish the change to the live system, either after approval or automatically, ideally with a way to roll it back.
If a step fails, the pipeline stops and notifies the team, so the faulty change does not move forward.
Why it matters when you commission software
- Fewer manual slips: steps written down as code are repeated the same way each time, so they are less likely to be forgotten.
- Earlier feedback: a broken change is found inside the pipeline instead of by customers.
- Smaller releases: frequent small changes are easier to review, and easier to undo, than a large batch released at once.
- A release history: the pipeline record shows which version went where, and which checks it passed.
What CI/CD does not do
- It does not replace good tests. A pipeline only runs the checks that exist. If no test covers booking or payment, a passing pipeline says nothing about them.
- It does not replace business review. Staff and customers still need to confirm that the software fits real work, for example through user acceptance testing.
- It takes effort to set up and maintain. It needs tests, environments, access and someone responsible for keeping it working.
- It is not needed to the same degree everywhere. A small website that is updated rarely may be fine with a simpler process.
Illustrative example: A small company runs an online booking system. A developer changes how time slots are selected. The pipeline builds the change, runs automated tests including the booking journey, and deploys it to staging. Staff try the new screen there, and a named person approves the release to the live system. If the booking test had failed, the change would have stopped before reaching staging and the developer would have been told.
What to ask your development team
- Is there an automated pipeline, and which steps does it run?
- Which tests run automatically, and which key journeys do they cover?
- Does every change go through a staging environment?
- Who approves a release to production, and how are releases scheduled?
- How can a release be rolled back, and who does it?
- After handover, who maintains the pipeline and holds its access keys and secrets?
Automated checks of critical user journeys can be one of the pipeline's steps, or can be run against a staging build or release candidate before users receive a change. To see how technine.io approaches this, visit our automated UI testing service. Once a system is live, releases, monitoring and maintenance are usually covered by managed support and an SLA.
Frequently asked questions
Is CI/CD only for large companies?
No. The ideas apply to projects of any size, and a pipeline for a small project can be modest. Many code hosting and cloud platforms include basic pipeline tools, but someone still needs to decide which checks to run and keep them up to date.
Does CI/CD mean the site is updated many times a day?
Not necessarily. CI/CD makes releases repeatable and less risky. How often to release is a business decision, and many teams release on a planned schedule.
Is CI/CD the same as DevOps?
No. DevOps is a broader way for development and operations teams to work together. CI/CD is one set of practices within it.