The problem CI/CD solves
Summary: until the 2000s, shipping software meant accumulating six months of work, merging everything at once, testing by hand for two weeks, then deploying on a Friday evening hoping nothing would break. This lesson details the five structural problems of that approach, and why they made continuous improvement impossible.
1. The world before — the six-month release
Here is what a typical delivery cycle looked like in a company in 2005.
The important point: this was not incompetence. It was the state of the art in an industry that did not yet have the tools to do otherwise.
2. The five structural problems
Each of these problems feeds the others, creating a vicious circle.
Problem 5 is the most insidious. It is a self-reinforcing vicious circle: the fear of deploying reduces the frequency, which increases the risk, which increases the fear. CI/CD breaks this circle by reversing the direction of the loop.
3. The real cost of detecting a bug late
There is a well-documented rule of thumb in software engineering: the later a defect is detected, the more it costs to fix.
Direct conclusion: the entire economics of CI/CD rests on bringing the detection of a defect closer to the moment it was written. This is the principle of shift left — moving validation towards the left of the timeline.
4. A realistic scenario — the Friday that goes wrong
Let's illustrate with a concrete incident, of the kind many teams have lived through.
What this incident reveals: the real problem is not the migration itself, it is the fact that it was never run automatically against a realistic dataset. A properly designed CI/CD pipeline would have executed that migration dozens of times before Friday evening.
5. What CI/CD changes concretely
CI/CD is not just about installing a tool. It reverses the logic of delivery.
This is the most important counter-intuitive point of CI/CD: deploying more often makes the system more stable, not less. It is exactly the opposite of most managers' intuition, and it is a result firmly established by the DORA research.
6. The six problems CI/CD solves directly
7. The numbers that illustrate the gap
Here is the measured gap between the highest-performing and lowest-performing teams, according to the DORA reports published every year since 2014.
| Indicator | Elite teams | Struggling teams | Gap |
|---|---|---|---|
| Deployment frequency | Several times a day | Between 1 and 6 months | ×1000 and more |
| Commit → production time | Less than one hour | Between 1 and 6 months | ×1000 and more |
| Change failure rate | 0 to 15% | 46 to 60% | ×4 |
| Time to restore | Less than one hour | More than one week | ×100 and more |
The striking observation: the teams that deploy the most often are also the ones whose deployments fail the least. Speed and stability do not oppose each other — they progress together.
These four indicators are the DORA metrics, detailed in lesson 6.
Remember in 30 seconds
- Before CI/CD, teams shipped every 3 to 6 months, in pain.
- Five structural problems: late integration, slow feedback, large change batches, artisanal deployment, fear of deploying.
- A bug detected in production costs about 100 times more than a bug detected while writing.
- CI/CD reverses the vicious circle: automating makes deployment routine, therefore frequent, therefore small, therefore low-risk.
- Counter-intuitive but proven: deploying more often makes the system more stable.
- Elite teams deploy several times a day with a failure rate four times lower.
Next: CI, continuous delivery, continuous deployment: three distinct notions →