CI/CD pipeline
A CI/CD pipeline is an automatic chain of work steps that checks new program code, assembles it, and delivers it through to the finished product. It ensures that software teams can publish changes daily without anyone having to run the checks by hand.
Dozens of people often work on a larger program at the same time. Each person changes small parts of the text that makes up the program. These changes must be merged, checked, and finally brought onto the servers where the program runs for users. A CI/CD pipeline handles exactly these steps automatically, in a fixed order. The letters stand for Continuous Integration, meaning ongoing merging, and Continuous Delivery or Deployment, meaning ongoing delivery. You can picture the whole thing as an assembly line: a change goes in at the front, and a checked, working version comes out at the back.
Why teams release daily instead of twice a year
In the past, companies collected changes for months and then released one large new version. That was risky. If something broke after launch, thousands of changes had to be searched through at once to find the bug. With small, frequent releases, on the other hand, the cause is almost always the most recent change.
The second reason is reliability. People forget steps, especially on Friday evenings. A pipeline runs exactly the same checks every time, in the same order, without exception. This turns releasing from a nerve-wracking special event into routine. Large providers such as Amazon or Google bring several thousand changes into operation per day this way.
This principle now also applies to AI systems. There it's called MLOps, meaning pipelines that check and deliver not just program code but also training data and finished models. A model can be formally error-free and still give worse answers than its predecessor. That's why such pipelines include additional quality measurements.
The stages of the assembly line
Everything starts in a shared storage location for the program code, usually managed with the tool Git. When someone uploads a change there, the pipeline starts automatically. The first step is the build: an executable program is built from the written text. If this already fails, everything is aborted immediately and the person receives a message.
Then come the tests. These are small additional programs that check whether individual functions still do the right thing. A test might ask, for instance, whether the shopping cart total is correct for three items. Security checks that look for known vulnerabilities often run in addition. Only once all checks are green does the process continue.
In the final section, the checked version is delivered. With Continuous Delivery, it is ready, but a person still has to press the final button. With Continuous Deployment, even this button is no longer needed. Often only one percent of users first receive the new version, so that problems are noticed early. If the measurements show errors, the system automatically switches back to the old version.
Green and red checkmarks in everyday developer life
Anyone looking at a software project on the GitHub platform sees a green checkmark or a red cross next to each change. This is the result of a CI/CD pipeline. The associated service there is called GitHub Actions; with other providers it's GitLab CI, Jenkins, or CircleCI. These pipelines are configured via a text file in the project that lists the steps.
In business news, the term usually comes up in the context of DevOps and cloud services. Companies like to justify investments with shorter time to market. The pipeline also becomes a topic after major outages, for example when a faulty update paralyzes computers worldwide. The question then is why the check stages didn't catch it.
A common misconception is that a pipeline guarantees error-free software. It only checks what someone has written as a test. Bad tests mean green checkmarks on a broken program. Automation thus shifts responsibility—it doesn't eliminate it.
