Tech, ExplainedCloud platforms and developer tools
Product

CI/CD pipeline

Every change built, tested and shipped automatically.

The pipeline starts when the repository receives a change, runs the build, the tests and the scanners, stores the image in the registry and deploys it on Kubernetes.
opens a page inside this one a page in the same scene a page in another scene a concept page a label only, with no page

A CI/CD pipeline is software that automatically builds every code change, runs its tests and security scans, and releases the approved version to the live system. CI stands for continuous integration: every developer's change is merged and tested many times a day, rather than in one large batch at the end of a month. CD stands for continuous delivery or continuous deployment. In continuous delivery, every change that passes the checks is ready to release when a person approves it. In continuous deployment, it is released automatically.

A pipeline is a list of stages that run in order. The team writes the list in a small file kept in the code repository. Each stage runs on a build server, a computer that does nothing but these jobs. If any stage fails, the pipeline stops, and the developer gets a message saying which check failed.

Take, for example, a telecom operator's self-care app, the app its customers use to recharge and check their data balance. A developer in Gurugram changes the screen that shows the remaining data. Her change is merged at 11:05 a.m., and the pipeline starts by itself.

The build stage turns the source code into a program that can run. It packs the program into a container image, one file that holds the program and everything it needs to run. This takes four minutes. Next, 2,300 automated tests run in parallel, in six minutes. Then the scanners run. A static application security testing (SAST) tool reads the code for security mistakes. Software composition analysis (SCA) checks every open-source library in the build against lists of known flaws. The app's screens are tested on real phones in a cloud test grid.

Every check passes. The pipeline stores the image in the artifact registry as version 7.3.0. It deploys this version to staging, a copy of the live system used for final checks. A release manager approves it. The pipeline then deploys it to production, the live system that customers use. To deploy means to install the new version on the servers and start it. Here the servers run on a Kubernetes platform, which replaces the old copies of the app with new ones a few at a time, so the app never stops. By 12:10 p.m., customers see the change.

Running the tests and scans this early, on every change, is called shifting left. It catches mistakes while they are cheap to fix. Without a pipeline, teams collect weeks of changes and release them together, often at night. When something then breaks, nobody knows which of the hundreds of changes caused it.

Jenkins, a free, open-source automation server, ran many of the first pipelines and still runs many older ones. Other companies sell the pipeline as part of a larger product, together with the repository and the registry.

Tech, Explained is a part of ingrid.fyi. Every page explains one piece of technology in plain words.