DevOps / cloud interviews

What is a CI/CD pipeline, and how does it work?

By Interview Clozo · Published 27 October 2026 · Last verified 26 October 2026 · 14 min read

A continuous integration and continuous delivery (CI/CD) pipeline is an automated sequence of stages that moves every code change through build, test and release. Continuous integration (CI) means merging and verifying changes often; continuous delivery or continuous deployment (CD) extends that to release. Order matters because a failing change stops at the first failed stage: in an illustrative example, running lint and unit tests before the build saves 1.13 minutes per commit.¹

In this article

Before you start
Why interviewers ask this
CI/CD pipeline from first principles
Worked example
Trade-offs and edge cases
How to answer it in an interview
Common mistakes
Follow-up questions
Sources

Before you start

This page is one step of the DevOps and cloud learning path.

Why interviewers ask this

A vague answer such as "code goes in and the app comes out" tells an interviewer nothing about whether you have ever run a release, so the follow-ups dig into the details. The question separates three things: whether you know what each stage is for, whether you can tell continuous delivery from continuous deployment, and whether you think about what happens when a stage fails.

A weak answer lists tool names. A strong answer names the stages in order, says what each one protects against, and explains why the order is chosen. A Staff-level answer adds the costs: slow pipelines, tests that fail at random, and how to reverse a release that passed every check and still broke production. This page builds that answer from zero.

CI/CD pipeline from first principles

CI/CD pipeline: A CI/CD pipeline is an automated sequence of stages that takes each code change from a commit through building, testing and release, stopping at the first stage that fails, so that problems are found while the change is still small and its author still remembers it.
Continuous integration: Continuous integration is a practice in which every team member merges changes into a shared codebase at least daily, and each merge is verified by an automated build that includes tests, so integration errors surface quickly.
Continuous delivery: Continuous delivery is a discipline of building software so that it can be released to production at any time; the pipeline keeps every version deployable, and a person decides when to release.
Continuous deployment: Continuous deployment is a release practice that extends continuous delivery by removing the human decision: every change that passes the whole pipeline is released to production automatically.

In plain words

Picture a factory line with inspection stations. Each part passes the stations in order. The quick, cheap inspections come first. A part that fails is sent back to its maker at once. Only parts that pass every station are shipped.

The analogy breaks in two places. A pipeline can run some stations side by side. A failed change is not scrapped; its author fixes it and pushes again.

In one precise sentence, a CI/CD pipeline is code that runs your build, tests and release steps automatically for every change, in a fixed order, and stops at the first failure.

Fowler's definition of CI is a practice, not a product. The Continuous Integration article by Martin Fowler (2024) says the contrast with painful integration comes from a simple practice of integrating frequently, not from an expensive tool.

Step 1: A commit starts the pipeline and the cheap checks run first

A push to the shared mainline starts the pipeline, and the fast, cheap checks run first. Fowler lists "every push to mainline should trigger a build" among the core practices of continuous integration. A CI agent is a machine that checks out the changed code and runs the stages on it. Platforms such as GitHub Actions let you define these workflows inside your repository.

The first stage is usually lint, which flags style problems and obvious mistakes, followed by unit tests, which check single functions in isolation. Input: a commit. Output: pass or fail, reported to the author. These checks take minutes at most and catch many mistakes cheaply, so they go first: a change that fails here never spends time in the slow stages.

Ordering changes only the wait of commits that fail, because a passing commit waits the full sum of its stages in any order. In the worked example below, putting lint and unit tests ahead of the build, rather than behind it, cuts the average wait from 15.13 to 14.00 minutes, a saving of 1.13 minutes per commit.¹ You now know what starts the run and why it begins cheap.

Step 2: The build turns the source into one artifact

The build compiles the code and packages it into an artifact, which is a packaged build output, such as a container image or an archive, that can be installed and run. Input: source that passed the fast checks. Output: one artifact with a unique, unchanging identifier, stored where later stages can fetch it.

Build once and promote the same artifact through every later stage. If each environment rebuilds from source, the thing you tested is not the thing you ship. Fowler also argues that you should keep in version control everything needed to build, but not what you build; he calls committed build products a smell, a sign that builds cannot be recreated reliably. A teammate with a bare laptop should be able to clone the repository and build the product. The artifact is the pipeline's hand-off object: after this step, every stage works on the same thing.

Step 3: Slower tests run against the artifact

Integration tests and other slow checks run against the artifact, in an environment that resembles production. Integration tests start the product together with the things it depends on, such as a database, and check that the parts work together. Input: the artifact. Output: pass or fail with logs.

Fowler lists testing in a clone of the production environment as a practice, because differences between the test setup and production hide faults until release. These tests are slow, so they run after the cheap checks have passed. If your pipeline has independent slow suites, running them side by side shortens the wait; the worked example shows the effect of one such overlap.¹ This stage is where most of the pipeline's time goes, which is why the order of the previous steps pays off.

Step 4: The deploy stage releases the artifact, and a gate decides who presses the button

The deploy stage installs the tested artifact in a staging environment, runs a few smoke tests (a handful of quick checks that the deployed system starts and responds), and then releases to production. Input: a tested artifact. Output: a running release.

The last decision defines the "CD". In continuous delivery the pipeline can deploy any version on demand, and a person chooses when. In continuous deployment every passing change goes live automatically. Fowler's Continuous Delivery page (2013) notes that you must do continuous delivery before you can do continuous deployment. It also describes a retailer that released first to its employees, then to an invited set of premium customers, and finally to all customers, a gradual rollout that limits the damage of a bad release.

Each stage runs only if the one before it passed, so a bad change stops at the earliest stage that can catch it.CC BY 4.0 — source: What is a CI/CD pipeline, and how does it work?

Step-by-step description

A commit starts the run; lint and unit tests go first.
The build packages one artifact.
Integration tests run on the artifact.
The artifact goes to staging, then production.

A commit starts the pipeline and fast checks run first.
A build produces one artifact, slower tests run on it, and a deploy follows.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.

Start Free Trial →

Worked example

Take an illustrative pipeline of six stages. The minutes per stage and the chance that a commit fails at each stage are invented for the exercise; the arithmetic that follows is computed.¹ Lint takes 1 minute with a 5% failure chance; unit tests take 4 minutes and 10%; the build takes 3 minutes and 3%; integration tests take 8 minutes and 8%; deploy to staging takes 2 minutes and 2%; smoke tests take 1 minute and 2%.

Run in sequence, the six stages take 19 minutes. If lint and unit tests run side by side, the wait is 18 minutes.¹ A commit passes every stage with probability 0.7328, so 0.2672 of commits fail somewhere, and because a failing commit stops early, a commit occupies the pipeline for 16.27 minutes on average rather than 19.¹

Now compare two orders of four checks: lint, unit tests, the build and integration tests. Lint and unit tests do not need the artifact, so they can move; integration tests run against the artifact, so they cannot run before the build. In fail-fast order (lint, unit tests, build, integration tests) the expected time per commit is 14.00 minutes. In build-first order (build, integration tests, unit tests, lint) it is 15.13 minutes. The saving is 1.13 minutes per commit, or 45.3 minutes a day at an illustrative 40 commits a day.¹ A commit that passes all four checks waits 16 minutes in either order.¹

In this illustrative pipeline a commit fails somewhere with probability 0.2672, and fail-fast order saves 1.13 expected minutes per commit over build-first order.
Quantity	Value (computed from illustrative inputs)
Total time, six stages in sequence	19 minutes
Total time, lint and unit tests side by side	18 minutes
Probability a commit passes every stage	0.7328
Probability a commit fails somewhere	0.2672
Expected minutes per commit, full pipeline	16.27
Expected minutes, four checks in fail-fast order	14.00
Expected minutes, four checks in build-first order	15.13
Saving per commit from fail-fast order	1.13 minutes
Minutes a passing commit waits, any order	16

Putting cheap, likely-to-fail checks first cuts the average wait, because failing commits stop sooner; a passing commit waits the same in any order.CC BY 4.0 — source: What is a CI/CD pipeline, and how does it work?

Text description of the diagram

Fail-fast order gives an expected 14.00 minutes per commit.
Build-first order gives an expected 15.13 minutes per commit.

Putting cheap, likely-to-fail checks first cuts the average wait, because failing commits stop sooner; a passing commit waits the same in any order. The saving looks small because only four checks are compared, and it grows as late stages get slower and as more commits fail early.

The precise rule: for independent checks that stop on failure, run them in ascending order of minutes divided by failure probability. Here lint scores 20 (1 minute over 0.05), unit tests 40 (4 over 0.10), the build 100 (3 over 0.03) and integration tests 100 (8 over 0.08).¹ The build and integration tests tie, and the build goes first because integration tests need its artifact. "Cheap and likely to fail" is the plain-words version of that rule.

Trade-offs and edge cases

The central choice is how much to automate at the end. Continuous delivery keeps a human approval before production; continuous deployment removes it. Fowler notes that a team practising delivery may choose not to deploy often, usually because the business prefers a slower rate of deployment. Which one fits depends on how costly a bad release is and how fast the business wants changes out, so a good answer states which one the team needs and why.

The three terms stack: delivery builds on integration, and deployment builds on delivery by removing the human approval.CC BY 4.0 — source: What is a CI/CD pipeline, and how does it work?

Text description of the diagram

Continuous delivery means the software is releasable at any time.
Continuous deployment releases every passing change automatically.

Pipelines have their own failure modes, and each has a standard response.

Every common pipeline problem has the same shape: a signal people learn to ignore, and a response that restores trust in it.
Problem	Effect	Common response
Flaky test	Red builds that mean nothing, so people stop reading them	Quarantine, then fix or delete the test
Slow pipeline	Developers batch changes, which defeats frequent integration	Run independent stages side by side, move cheap checks first
Broken mainline	Everyone's next merge is blocked	Fix or revert immediately
Bad release that passed	Users hit a fault no check found	Roll back to the previous artifact, release gradually

A flaky test is a test that sometimes passes and sometimes fails on the same code. Fowler's practices include fixing broken builds immediately and keeping the build fast, because a pipeline people distrust or avoid stops doing its job. Rollback is easiest when artifacts are immutable and stored: you redeploy the previous one. Database changes are the awkward case, because the older artifact may not match a newer schema, so schema changes are usually made in steps that old and new versions can both tolerate. Pipelines also cost compute time, so a team trades cost against speed when it decides how many stages to run on every commit.