What CI/CD is and why

Why

Picture a team with no automation. Five developers spend a week writing code on their own branches. On Friday everyone merges into one branch, and then:

• one person's code breaks another's (conflicts, incompatible changes);
• "it works on my laptop" but not on the server;
• nobody ran the tests locally because "it takes too long";
• deploy looks like this: a senior engineer SSHes in and copies files by hand, hoping nothing was forgotten.

Every release becomes stressful and eats an evening. The longer code lives unmerged from the main branch, the more painful the integration. CI/CD solves this by merging changes often and letting automation handle checks and deploys.

What the letters mean

CI (Continuous Integration). Every developer merges their changes into the shared branch often (several times a day), and automation runs a build and tests on every change. If you broke something, you find out in minutes, not in a week.

CD stands for two different things, and it's important not to mix them up:

• Continuous Delivery — after CI, a ready-to-ship artifact is built, and you can ship it to prod at any moment with one button. The decision whether to ship stays with a person.
• Continuous Deployment — there's no button: a change that passed all checks goes to prod on its own, without human approval.

Deployment is impossible without Delivery: to deploy automatically, you first need to be able to ship at any moment. The difference between the two gets its own lesson because it's a common interview question.

How it works

A pipeline usually runs roughly this chain on every change:

commit -> build -> lint -> test -> package the artifact -> deploy

These used to be manual steps that people forgot or did differently each time. Now they're described as code, live in the repository, and run the same way every time.

A few words you'll meet in every CI tool:

• Job — one task in the pipeline: build, run tests, package.
• Stage — a phase of the pipeline (build, test, deploy), containing one or more jobs.
• Runner — the machine or container that actually executes a job.
• Artifact — the file a job produced (a jar, an archive, a binary) that gets passed to the next job or shipped out. A container image is also a build result, but it's usually pushed to a registry rather than kept as a job artifact.

The order of steps matters. The pipeline stops on the first job that fails, and everything after it never runs. If packaging comes after tests, broken code simply never turns into an artifact and never travels further.

What changes in your work

You see breakage right away: tests fail on push, and you find out within a minute instead of a week later, when it's no longer clear where things broke. Releases get smaller: shipping 10 lines is safer than shipping 10,000 accumulated over a month. Deploy becomes a routine button that anyone on the team can press, not just the one senior engineer who knows how. A machine never forgets a step and never confuses prod with staging.

DORA metrics

How do you know a team's delivery is good? The DORA research program has measured this with the same metrics for years. The classic set, the one that comes up in interviews, has four:

• Deployment Frequency — how often you ship to prod.
• Lead Time for Changes — how long it takes from commit to prod.
• Change Failure Rate — what share of deploys breaks prod and needs urgent intervention.
• Mean Time to Recovery (MTTR) — how fast you recover after such a failure.

The metrics have been revised. In 2023 MTTR was renamed Failed Deployment Recovery Time: now it measures recovery specifically after a failed deploy, not after any failure. In 2024 a fifth metric was added, Deployment Rework Rate: the share of unplanned deploys that had to happen because of a prod incident. DORA's site now lists five metrics, named: Change Lead Time, Deployment Frequency, Failed Deployment Recovery Time, Change Fail Rate, Deployment Rework Rate.

The first two show speed, the rest show stability. A good team ships often while rarely breaking prod.

Common mistakes

• Mixing up CI and CD. CI builds and tests every change. CD ships to prod. The phrase "CI shipped it to prod" in an interview gives away the confusion.
• Treating Delivery and Deployment as the same thing. The difference is one thing: who presses the release button, a person or automation.
• Fixing a red pipeline by editing the test. A test describes how the code is supposed to work. Bend the test to fit broken code, and the pipeline turns green while the bug ships to prod.
• Putting packaging and deploy before tests. Then the artifact gets built from broken code too, and the checks lose their point.
• Letting changes pile up for a week. The bigger the change, the longer it takes to find what broke, and the riskier the release.
• Calling only the old four DORA metrics "all of them." There are four classics, but the current DORA list is longer, and MTTR has a different name in it now.

What they'll ask you in an interview

Short answers you should be able to give:

• "How does CI differ from CD?" CI builds and tests every commit. CD delivers a ready artifact to prod: either a person presses the button (Delivery) or the artifact ships itself (Deployment).
• "How does Continuous Delivery differ from Continuous Deployment?" With Delivery the artifact is ready and a person triggers the release. With Deployment it's the same, just without the button.
• "What is a pipeline?" A sequence of steps described as code (.gitlab-ci.yml, .github/workflows/*.yml): build, test, package, deploy. It lives in the repository and runs the same way every time.
• "Name the DORA metrics." Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR. Plus know that MTTR is now called Failed Deployment Recovery Time, and since 2024 there's a fifth, Deployment Rework Rate.
• "What are stage, job, runner, artifact?" Definitions above, in "How it works".

What you'll need for the tasks

• Lab 1: Docker 20.10 or newer and bash. The pipeline runs with bash run-pipeline.sh in a disposable python:3.12.7-alpine container. Reading the log: the === job: ... === headings and the final PIPELINE: ... line.
• Lab 2: bash only. You'll need the definitions of Deployment Frequency, Change Fail Rate, and Failed Deployment Recovery Time from the "DORA metrics" section.
• Commands: cat, grep -c, any text editor.

In the next lesson we'll dig into CI in detail: what runs on every push and why a "green main" is a team rule.