What CI/CD Means, and How a Pipeline Works

CI and CD mean continuous integration and continuous delivery: merging code changes into one shared codebase often, checking every change automatically, and keeping the software ready to release at any moment. The CD half can also mean continuous deployment, where every change that passes the checks goes live without a person approving it. The automated route a change takes from a developer's commit to running software is called a CI/CD pipeline.

What CI/CD means, one term at a time

The abbreviation hides three ideas, and two of them share the same letters.

Continuous integration (CI)

Continuous integration is the habit of merging everyone's work into one main branch frequently, ideally at least once a day, and running an automated build and test suite on every change. The word "integration" is literal. Without it, developers work on separate branches for weeks and then lose days finding out that their changes do not fit together. With it, a conflict or a broken test shows up within minutes, while the change is small and its author still remembers what they did.

CI is a practice first and a tool second. A server that runs tests on a branch nobody merges for three weeks is not continuous integration, whatever the dashboard calls it.

Continuous delivery (CD)

Continuous delivery means every change that passes the automated checks is built, packaged and ready for production. Releasing is a routine action the team can take at any time, usually one click, but a person still decides when.

Continuous deployment (also CD)

Continuous deployment removes that decision. If the pipeline passes, the change goes to production on its own. There is no release meeting and no approval step, and a busy team may release many times a day.

	Continuous delivery	Continuous deployment
Who releases to production	A person approves, the pipeline does the work	The pipeline, automatically, on every passing change
What you have to trust	Tests good enough to make a release boring	Tests, monitoring and rollback good enough to remove the human check
Where it fits	Most teams, regulated products, mobile apps that wait on store review	Web services with strong test coverage and fast rollback

My view is that most teams should aim for continuous delivery first. It gives you nearly all of the benefit, and it keeps a human in the loop while you learn how far you can trust your tests. Continuous deployment is a sensible next step for web services once rollback is fast and monitoring is good.

What is CI/CD in DevOps?

DevOps is the broader idea that the people who build software and the people who run it should share responsibility, tools and feedback, instead of one group handing releases to the other and hoping. CI/CD is the most concrete part of that idea. It is the machinery that makes shared responsibility practical: the same automated process builds, tests and ships every change, and everyone can see what happened.

It sits alongside related practices such as infrastructure as code, which puts servers and networks under the same version control and review as the application. The glossary entry on CI/CD has the two-paragraph version if you need to explain it to a colleague.

What a CI/CD pipeline does, stage by stage

A CI/CD pipeline is an ordered list of automated steps that runs whenever the code changes. Each stage is a gate. If one fails, the pipeline stops and tells the author, and nothing further happens. The usual order looks like this:

1. Trigger. A developer pushes a commit or opens a pull request. The CI system notices and starts a run on a clean machine or container, so the result does not depend on anyone's laptop.
2. Install and build. The pipeline fetches dependencies and compiles or bundles the code. If it does not build here, it does not build.
3. Static checks. Linters, formatters and type checkers run next because they are fast and cheap. Scanners for vulnerable dependencies and accidentally committed secrets often sit at this stage too.
4. Automated tests. Unit tests go first because they finish in seconds. Integration tests follow, using a real database or a real queue. A small number of end-to-end tests drive the application the way a user would.
5. Package. The pipeline produces one versioned artefact, commonly a container image tagged with the commit it was built from. That same artefact moves through every environment. You do not rebuild for production, because a rebuild is a different thing from the one you tested.
6. Deploy to staging. The artefact goes to an environment that resembles production, and a few smoke tests confirm that it starts, connects to its database and answers requests.
7. Release to production. After a manual approval (delivery) or straight away (deployment), the pipeline rolls the new version out. Good pipelines do this gradually: a rolling update, a blue-green switch between two environments, or a canary release that sends a small share of traffic to the new version first.
8. Verify and roll back. Health checks and error rates are watched after the release. If they turn bad, the previous version is one step away, and ideally the pipeline takes that step itself.

Stages one to five are the CI half. Stages six to eight are the CD half.

A simple CI/CD pipeline example

Take a small web application: an API, a front end and a database. A developer opens a pull request. The pipeline installs dependencies, runs the linter and the type checker, then the unit tests, then the integration tests against a throwaway database created for that run. A reviewer sees a green tick before reading a single line.

When the change is merged to the main branch, the pipeline runs the same checks again, builds a container image, tags it with the commit identifier and pushes it to a registry. It deploys that image to staging and runs the smoke tests. Then it waits. Someone presses approve, and the pipeline rolls the same image out to production a few instances at a time, watching the health checks as it goes.

Written down, that pipeline has roughly this shape. It is a generic sketch, not valid syntax for any one tool. Every CI system has its own keywords, but nearly all describe the same things: when to run, which stages exist, and what each stage does.

pipeline:
  on:
    pull_request: [check]
    push_to_main: [check, package, staging, production]

  stages:
    check:
      steps:
        - install dependencies
        - run linter and type checks
        - run unit tests
        - run integration tests   # against a throwaway database

    package:
      steps:
        - build container image
        - tag image with commit id
        - push image to registry

    staging:
      steps:
        - deploy image to staging
        - run smoke tests

    production:
      requires: manual approval   # remove for continuous deployment
      steps:
        - deploy image gradually
        - check health and error rate
        - roll back on failure

Containers are common because an image is a convenient artefact, but they are not required. A pipeline that copies a build to a virtual machine and restarts a service is still CI/CD. The Docker and Kubernetes comparison covers where each one earns its place.

What CI/CD changes for a business

The benefit is usually described as speed. I think that undersells it. The real change is the size of each release.

• Smaller releases carry less risk. A release containing three changes has three things that can go wrong. A quarterly release containing three hundred has three hundred, plus the ways they interact. When a small release breaks something, the cause is one of a handful of changes.
• Fixes reach users quickly. If shipping is routine, a bug fix follows the same path as any other change. Nobody needs to bypass the process at two in the morning, which is when processes get bypassed badly.
• The release process stops living in one person's head. A pipeline is a file in the repository, reviewed and versioned like any other. The engineer who "knows how deploys work" can go on holiday.
• Product decisions get faster feedback. A feature that reaches users soon after it is finished tells you whether it was worth building.

To measure the effect, the four measures popularised by the DORA research programme are a sensible starting point: how often you deploy, how long a change takes to reach production, how often a release causes a failure, and how long recovery takes. Track your own numbers, and be wary of anyone promising a specific improvement before they have seen your codebase.

There are honest limits. A pipeline does not make poorly designed software good, and automated tests only catch what someone thought to test.

Continuous integration tools: the common choices

The concepts above are the same across continuous integration tools. What differs is where the tool runs and how much of it you look after. Four names come up most often:

• GitHub Actions. Built into GitHub. Workflows are YAML files stored in the repository, and jobs run on machines GitHub hosts or on runners you provide.
• GitLab CI/CD. Built into GitLab. A single YAML file in the repository defines the pipeline, and jobs run on runners that GitLab hosts or that you register yourself.
• Jenkins. An open source automation server that you host and maintain. Pipelines are usually defined in a Jenkinsfile kept with the code, and a large plugin ecosystem covers most integrations.
• CircleCI. A dedicated CI/CD service that connects to a repository hosted elsewhere, with its configuration kept in the repository as YAML.

The large cloud providers also have their own pipeline services. I would not rank any of these. For most teams the practical choice is the tool that sits next to the code, because it removes an integration and a set of credentials. Self-hosting makes sense when jobs must run inside your own network, and it brings the upkeep of the build machines with it.

What goes wrong with a CI/CD pipeline

Slow pipelines

A pipeline that takes most of an hour changes behaviour. Developers stop waiting for it, batch several changes together to avoid the wait, and the small releases you wanted turn back into large ones. The usual fixes are plain: cache dependencies between runs, run tests in parallel, put the fastest checks first so failures arrive early, and keep the slow end-to-end suite to the journeys that matter.

Flaky tests

A flaky test passes and fails without the code changing. One is an annoyance. A dozen teach the whole team to press re-run when the pipeline goes red, and from that point a red pipeline carries no information. In my experience the causes are usually timing assumptions, state shared between tests, dependence on test order, or calls to a real network service. Treat a flaky test as a defect: quarantine it the day it appears, then fix it or delete it.

Secrets in config

Pipelines need credentials to deploy, and that makes them a target. The common mistakes are API keys written directly into the pipeline file, secrets printed into build logs, and one all-powerful production credential shared by every job. Use the secret store your CI tool provides, give each job only the access it needs, and prefer short-lived credentials over stored long-lived keys where your cloud provider supports them. Be careful about what runs on changes from outside contributors, because a pipeline executes whatever the change tells it to. I cover the wider habit in security by design versus bolt-on.

How to start small

You do not need the full eight stages on day one. I would build it in this order, and stop at any point where the next step is not yet worth it:

1. Put everything in version control with one main branch, and keep feature branches short-lived.
2. Make the build a single command that works on a clean machine.
3. Run that command and whatever tests you already have on every pull request. Five tests are enough to begin.
4. Block merging when the pipeline is red. This is the step that turns a tool into a practice.
5. Script the deployment to one environment, usually staging, by automating exactly what you do by hand today.
6. Add production behind an approval button, with a rollback step you have tested.
7. Add tests where bugs have actually appeared, and watch the pipeline's run time as closely as its pass rate.

If the test suite is the gap, our automation testing page covers what is worth automating and what is not. Setting up a pipeline, or making an existing one faster and safer, is part of our DevOps service.

Frequently asked questions

What do CI and CD stand for?

CI stands for continuous integration. CD stands for continuous delivery or continuous deployment, depending on whether a person approves each production release (delivery) or the pipeline releases automatically (deployment).

What is a CI/CD pipeline?

A CI/CD pipeline is the automated sequence that takes a code change through building, testing, packaging and deployment. It runs on every change, stops at the first failure, and produces a record of what was released and when.

What is CI/CD in DevOps?

It is the automation at the centre of DevOps. DevOps is a way of working in which development and operations share responsibility for running software, and CI/CD is the tooling that lets them ship small changes frequently and safely.

Which continuous integration tools should a small team use?

Usually the one built into wherever the code is already hosted, such as GitHub Actions or GitLab CI/CD. It needs the least setup and no separate server. Jenkins and CircleCI are sound choices when you have a reason to run CI separately from your code host.