In the previous lesson we defined what continuous integration, continuous delivery and continuous deployment are. Now comes the uncomfortable question: is it worth it?. Setting up a pipeline takes time, it has to be maintained, it burns machine minutes that get billed and, if it is done badly, it produces more frustration than value. This lesson is deliberately honest: first we will go through the real benefits — with the detail of how each one is measured, because a benefit that is not measured is an opinion — and then we will put the costs on the table, along with the scenarios where CI/CD contributes little. We will use Reservalia as our thread, whose starting point we already know: three-hour manual deployments on Fridays and two serious incidents last quarter. By the end, you will have concrete arguments to defend — or to rule out on solid grounds — an investment in CI/CD.

1. The scales: two columns, not one
2. Shorter lead time
3. Early defect detection and the growing cost per phase
4. Lower risk thanks to small batches
5. Repeatability and traceability
6. Objective feedback for the team
7. Team morale and on-call load
8. Summary table: benefit → how it is measured → risk if you skip it
9. The costs, unsweetened
10. When CI/CD contributes little
11. Common mistakes and tips
12. Exercises
13. Conclusion

Most material on CI/CD presents a list of benefits and stops there. That produces teams who set up a pipeline because it is fashionable, abandon it three months later and conclude that "CI/CD does not work". The reality is a set of scales:

The answer is usually "yes", but not always, and certainly not to the same degree for a team of 3 people with an internal project as for one of 40 with a paid SaaS. Section 10 covers the exceptions.

Lead time is not coding time. It is the total time from the moment the code is written until the user is using it. At Reservalia today, that journey looks like this:

Notice where the longest block sits: it is not coding, it is waiting. Diego's change is finished on Tuesday and reaches users on the Friday of the following week. The deployment window imposes a wait of up to 9 days for a change that takes 3 days to write.

And that wait is not neutral: while the change waits, it piles up with other changes, forming the large batch we will discuss in section 4.

An automated pipeline attacks two things at once:

1. It removes the waiting window. If deploying takes 8 minutes and requires nobody to coordinate, there is no need to bunch deployments up on Fridays.
2. It removes the manual execution time. Diego's 3 hours become machine time, and machine time in parallel with other work at that.

Reservalia's before and after, with the figures from its own case:

Those 156 hours are almost a full month of full-time work dedicated exclusively to copying files. That is the figure Marta will take to the budget meeting.

Careful with the figures. The ones in this table come from the Reservalia case, which is fictional but coherent. Avoid quoting generic percentages of the "CI/CD improves productivity by 40%" variety: those are numbers that circulate without a source and do not survive a single question. Measure your process. Lesson 01-05 will give you the instruments to do so.

A defect does not cost the same depending on when it is discovered. The reason is purely practical: the later it shows up, the more context has been lost and the more people are involved.

You need no study to understand the curve: fixing a bug you discover 4 minutes after writing it is incomparably cheaper than fixing the same bug three weeks later, in the small hours, in a codebase that has already moved on.

Continuous integration works by pushing detection towards the left of that line. It is called shift left, and it is the main reason CI exists.

One of the two serious incidents of the quarter was this: Diego changed the type of the duration_minutes column from integer to numeric in order to allow 90.5-minute appointments. There was a test that caught it... but nobody ran the tests that Friday. The application returned a 500 error on every appointment creation for 40 minutes, until a customer called.

With CI, that failure would have surfaced before the pull request was merged, with Diego looking at the screen and the context fresh in his mind. Cost: five minutes. Without CI: 40 minutes of downtime, lost bookings, a call from an angry customer and an afternoon of post-mortem.

The difference is not in the quality of the test. The test already existed. The difference is that a human has to remember to run it, and a pipeline does not.

When Diego deploys on Friday, he is not deploying a change: he is deploying everything accumulated over the week. Let us say 14 commits from 3 people.

If something breaks, which of the 14 changes is the culprit? Nobody knows. The manual bisection phase begins, in production, with affected users and in a hurry.

Let us compare the two ways of working:

The paradox many people struggle to accept is this: deploying more often reduces total risk, even though it increases the number of deployments. Because the risk is not in the act of deploying, but in the amount of unverified change that act releases all at once.

Both serious incidents of the quarter happened during a Friday deployment. That is not a statistical coincidence: the only deployments they do are Friday ones, and each of them releases a week of unverified changes. Reducing batch size is the most direct lever the team has for reducing its change failure rate (we will measure it in 01-05).

At Reservalia today, if Diego is on holiday, nobody knows how to deploy. The knowledge lives in his head and in an out-of-date Notion document. That is a business risk, not just a technical one: it is called a bus factor of 1.

A pipeline turns that tacit knowledge into versioned, executable code:

• It is in the repository, anyone can read it.
• It is reviewed in pull requests, like any other change.
• It runs the same way no matter who launches it.
• If anything in the process changes, it is recorded in the history with an author and a reason.

These are questions Nuria, the SRE, cannot answer today and that a pipeline answers in seconds:

An example of the information a pipeline records for each deployment — we will use this structure in lesson 01-05 to calculate metrics:

With this record alone, repeated on every deployment, you can already answer every question in the table above. And, as we will see, calculate three of the four DORA metrics as well.

One of the least cited and most transformative benefits: the pipeline replaces opinions with facts.

Without CI, a team's conversations sound like this:

• — "I think this is ready."
• — "It was working for me yesterday."
• — "We should test it a bit more thoroughly, shouldn't we?"

With CI, they sound like this:

• — "The PR is green: build, 340 tests, coverage and lint."
• — "createAppointment › rejects overlaps is failing, line 88."

The difference is that the second conversation has no ego in it. The pipeline criticises nobody: it reports. This has three concrete effects:

1. It depersonalises criticism. It is not "Marta says your code is wrong": it is "the type-checking step failed". Human review is then free for what it genuinely adds — design, readability, product decisions — instead of being spent on formatting and typos.
2. It gives a shared definition of "done". Defining done as "the pipeline is green and the PR is approved" puts an end to endless arguments.
3. It makes the real state of the project visible. Anyone can look at the run history and see whether the project is healthy or has been red for three days.

This benefit is hard to quantify and yet it is usually the one that decides whether a team perseveres with CI/CD or abandons it.

Go back to Diego's Friday afternoon. What the spreadsheet does not capture:

• Anticipatory anxiety. From Thursday onwards, Diego knows Friday is waiting for him. He works worse on Thursday.
• A weekend on standby. If something breaks on Friday at 19:00, somebody's weekend breaks with it.
• Fear of changing things. When deploying is frightening, people avoid refactoring, avoid updating dependencies and accumulate technical debt. Fear of deployment becomes a tax on code quality.
• Concentrated knowledge. Diego is the only one who knows how to deploy and that, which looks like power, is in practice a chain: he cannot truly switch off on holiday.
• Turnover. Burnout from avoidable incidents is one of the usual reasons people change jobs. Replacing a developer costs months of productivity.

Nuria, who carries the pager, gets very concrete improvements:

The sentence that sums up the cultural change: a good CI/CD system turns an emergency into a procedure.

CI/CD does not fix a broken team culture. If your organisation blames people for incidents, automating deployment will only make the blame arrive faster. Automation amplifies the existing culture: if it is healthy, it reinforces it; if it is toxic, it accelerates it.

This table is the lesson's executive summary. It is exactly the material Marta needs to justify the investment:

The standard, industry-recognised way of measuring several of these benefits is the DORA metrics (deployment frequency, lead time for changes, change failure rate and time to restore service). We will develop them in detail in lesson 01-05, along with the practical way of instrumenting them at Reservalia. For now, just remember that they exist and that they give you a common language for discussing this with management.

Everything above comes with a bill. Ignoring it is the fast track to abandoning the pipeline three months in.

Writing the first useful pipeline is not a couple of afternoons. For a project the size of Reservalia, a realistic estimate:

And there is an added cost that is hard to swallow: during those weeks, both processes coexist. You keep deploying by hand while you build the automated one. It is temporary double work, and it is the phase in which most projects are abandoned.

The pipeline is software and, like all software, it rots if it is not looked after:

• Third-party actions and plugins publish new versions and drop old ones.
• The runners' base images change (an operating system update on the runner can break a build).
• Node, Python or Java versions reach end of life.
• Credentials expire and have to be rotated.
• Every new product feature may require a new step in the pipeline.

Budget for half a day a month of maintenance on a small project, plus the spikes when something big changes. We will cover this thoroughly in module 4.

This is hard cash. Hosted CI/CD providers bill per minute of execution, and free allowances run out sooner than you would think.

Let us do the maths for Reservalia:

Three thousand minutes a month on a small project. With larger runners (more CPU and RAM), the price per minute multiplies. And there is a multiplier that surprises many people: in a build matrix (for example, testing on Node 18, 20 and 22 × Linux and macOS), the minutes are multiplied by the number of combinations, and macOS runners are usually billed at a multiple of the Linux price.

The levers for keeping this under control — dependency caching, conditional execution based on which folders changed, cancelling stale runs, parallelising properly — are the subject of module 4, lesson 04-04.

A flaky test is one that sometimes passes and sometimes fails without the code having changed. Typical causes: clock dependencies, fixed waits in interface tests, execution order, shared state in the database, race conditions, calls to external services.

They are the most effective poison against a pipeline, and the mechanism is psychological:

The damage is not the time lost in retries: it is that they destroy the signal. A pipeline nobody trusts is worse than no pipeline at all, because it costs money and gives false reassurance. The only sustainable policy is to treat a flaky test as a high-priority failure: it gets fixed, or it goes into explicit quarantine with a deadline, never "retry and move on". We will tackle this in lesson 02-04.

Adding CI/CD adds one more system the team has to understand: YAML with its syntax and its traps, the tool's execution model, containers, secrets management, cloud permissions. For a junior team, this is real and has to be budgeted for. The good news is that it is transferable knowledge: the concepts in module 1 hold for any tool, as we will see in 01-03.

Honestly, there are contexts where the investment does not pay off — or only partly does:

Note a nuance that comes up several times: even where continuous deployment does not apply, continuous integration almost always does. The bottom rung of the 01-01 pyramid pays off in practically any context with more than one person and more than a month of life.

Mistake 1: selling CI/CD with generic figures from the internet. "Teams doing CI/CD deploy 200 times more often" is a headline without context. If you take it into a meeting, the first question will be "where does that come from?" and you will have no answer. Take your numbers: 156 hours a year of Diego copying files is an argument nobody argues with.

Mistake 2: presenting only the benefits column. If you promise everything will be faster and leave out the 4 weeks of setup and the 3,000 minutes a month, the first invoice will destroy your credibility. Present the complete set of scales; it inspires far more confidence.

Mistake 3: measuring success by "we have a pipeline". Having a ci.yml is not an outcome. The outcomes are: lead time dropped from 9 days to 2 hours, or the number of failed deployments fell from 2 a quarter to 0. Define the metric before you start.

Mistake 4: automating deployment before you have tests. It is the wrong order and the most common one. Automating a deployment without reliable tests only manages to take the errors to production faster and more often. Tests first, deployment automation second.

Mistake 5: tolerating flaky tests "temporarily". That "temporarily" becomes permanent in three weeks and drags the credibility of the whole pipeline down with it. Treat them as high-priority bugs from day one.

Tip 1: measure your baseline this very week. Time the next manual deployment. Count how many days pass between commit and production across the last 10 changes. Without a baseline, six months from now you will be unable to prove anything.

Tip 2: start with the most painful step. Do not try to build the complete pipeline. If what hurts most is that nobody runs the tests, start with a workflow that runs the tests on every PR. A visible benefit in the first week buys you the team's support for the rest.

Tip 3: budget for maintenance from the outset. Set aside half a day a month in your planning. If pipeline maintenance is always work "done in the gaps", it will never get done and the pipeline will degrade until somebody switches it off.

Tip 4: count the non-technical benefits too. The fact that Diego can go on holiday without being the only person who knows how to deploy is a business continuity benefit. It tends to convince management more than any technical argument.

Marta has 15 minutes with management to ask for 4 weeks of Diego's time dedicated to building the pipeline. With the data from the case — weekly three-hour deployments, two serious incidents last quarter, a team of 3 people — prepare:

1. The current annual cost in hours of the manual deployment process.
2. An estimate of the cost of the investment (setup + first-year maintenance), in hours.
3. The break-even point: after how many months has the investment paid for itself, counting deployment time only?
4. Two benefits that do not appear in that calculation but that you should mention anyway.

Assume an 8-hour working day and 20 working days per month.

For each scenario, decide what you would recommend — full CI, CI + continuous delivery, continuous deployment or nothing for now — and justify it in two or three sentences:

1. A freelance developer maintains a statically generated personal blog. She publishes one article a month. She has no tests.
2. A 12-person startup with a paid B2B SaaS. They have 400 tests and reasonable coverage. They deploy every two weeks, stressfully.
3. An 8-person team developing the dosing software for a hospital infusion pump. Every version requires certification by a regulatory body.
4. A 5-person team that has inherited a 12-year-old PHP monolith with no automated tests at all. They deploy over FTP and want to "get CI/CD in right now".

Another company's team, Citalia, set up CI/CD 8 months ago. These are their current figures:

• The pipeline takes 47 minutes on a pull request.
• Of the last 100 runs, 31 failed; on retrying them without changing anything, 26 passed.
• The team's policy is "if it fails, hit Re-run jobs".
• The runner-minutes bill has gone up 80% in 4 months.
• Last week a bug reached production that had a test covering it.

Answer:

1. What is the root problem, and which of these are consequences of it?
2. Which benefit from this lesson have they lost, even though the pipeline "works"?
3. Propose three actions ordered by priority.

Solution to Exercise 1

1. Current annual cost of manual deployment

2. Cost of the investment (first year)

3. Break-even point

An honest reading: the purely accounting return arrives around the one-year mark. This is important and you have to say it: if you sell "it pays for itself in two months", you will be found out. What clearly makes the investment worthwhile are the benefits that are not in this calculation.

4. Benefits outside the calculation

• Reduced business risk: production incidents on a booking platform do not cost only engineering hours; they cost lost appointments for Reservalia's customers, and reputation. A 40-minute outage during business hours affects real bookings.
• Eliminating the bus factor: today, if Diego falls ill, Reservalia cannot deploy even a critical fix. That is a business continuity risk, not an inconvenience.
• Speed of reaction: with automated deployment, fixing a bug spotted at 10:00 is a matter of minutes, not of waiting until Friday.
• Ability to grow: the current process does not scale to 6 people. If Reservalia hires, the bottleneck is structural.

Solution to Exercise 2

1. Static personal blog: nothing for now, or minimal CI. One article a month, no tests, no users depending on it. The most that can be justified is a trivial workflow that builds the site and deploys the HTML — which, in fact, many static hosts already offer with no configuration. Building an elaborate pipeline here is a learning exercise, not a necessity.

2. B2B SaaS startup: full CI + continuous delivery, with an eye on continuous deployment. This is the scenario where CI/CD pays off most. They have tests and reasonable coverage — the necessary foundation — and the stress of fortnightly releases indicates batches that are too large. Recommendation: CI on every PR straight away, and automate deployment up to staging and up to production with a manual gate. When the change failure rate falls in a sustained way, they can consider removing the gate.

3. Hospital infusion pump: full CI, continuous delivery up to the validation environment, and continuous deployment ruled out. The regulatory framework demands documented evidence and per-version certification; deploying automatically is unviable. But CI contributes enormously here: exhaustive automated testing, complete traceability of what was built and with what (precisely what an auditor asks for), and reproducible builds. The manual gate is not a shortcoming of the pipeline: it is a requirement of the domain.

4. PHP monolith with no tests: minimal CI, but the order matters. The mistake would be to automate deployment first: they would succeed in taking errors to production faster. Recommended order: (a) set up the build-and-run-tests pipeline, even if there are barely any tests at first; (b) add tests for the 5-10 business-critical paths — the things a user must never lose the ability to do; (c) add static analysis, which delivers immediate value without writing tests; (d) only then, automate deployment, starting with an environment that is not production. We will develop this particular case in lesson 05-04.

Solution to Exercise 3

1. Root problem and consequences

The root problem is the flaky tests: of 31 failures, 26 passed on retry without anything being touched. That means roughly 84% of the failures are noise. Everything else is a consequence:

• The "hit Re-run" policy is an adaptation by the team to the noise, not a cause.
• The runner bill went up 80% partly because of the retries of 47-minute runs.
• The bug that reached production despite having a test covering it is the final, predictable consequence: the test genuinely failed, somebody retried out of habit, it slipped through on the second attempt, or the red was ignored.

There is a secondary, independent problem: 47 minutes of pipeline on a PR is too much. It breaks the fast feedback loop — people switch tasks while they wait — and it multiplies the cost of every retry.

2. Benefit lost

They have lost objective feedback (section 6) and, with it, early defect detection (section 3). The pipeline still runs, but it has stopped being a reliable signal: a red no longer means "there is a problem", it means "try again". The moment a team stops believing the result, the pipeline goes from asset to liability: it costs money and gives false reassurance. They are paying the entire costs column without collecting on the benefits one.

3. Actions by priority

1. Ban blind retries and quarantine the flaky tests. Instrument the detection of unstable tests (flag the ones that fail and then pass with no code change), take them out of the blocking suite and put them on an explicit list with an owner and a deadline. Immediate goal: make a red mean something again. Without this, nothing else matters.
2. Actually fix the flaky tests, starting with the most frequent ones. They usually cluster in a handful: fixed waits, clock dependencies, state shared between tests. Attacking the top 5 normally removes most of the noise.
3. Bring pipeline time on a PR below 10-15 minutes. Parallelise jobs, cache dependencies, run only what is affected by the modified files, and move the slow suites (full end-to-end) to a post-merge or nightly run. This reduces both the bill and the temptation to bypass the process.

A fourth, reinforcing action: publish a dashboard with the percentage of runs that are green first time. It is the metric that makes it visible whether the problem is improving or not.

In this lesson we have put the complete set of scales on the table:

• The benefits are real and measurable: faster delivery (Reservalia recovers ~156 hours a year in deployment time alone), early defect detection — whose cost grows dramatically with each phase defects pass through — lower risk from small batches, repeatability that removes the bus factor, traceability that answers questions that are impossible today, objective feedback that depersonalises criticism, and a direct impact on team morale and on-call load.
• Every benefit has its way of being measured. A benefit that is not measured is an opinion, and opinions do not survive a budget review.
• The costs are real too: weeks of setup, ongoing maintenance, thousands of runner minutes a month even on small projects, and above all the poison of flaky tests, which destroy the signal and with it the entire value of the system.
• CI/CD is not universally profitable. In prototypes, one-person projects or heavily regulated software, the continuous deployment part contributes little. Continuous integration, by contrast, pays off in almost any context with more than one person involved.

We have mentioned several times that there is a standard way of measuring all this: the DORA metrics. We will devote the whole of lesson 01-05 to them.

But before measuring anything we have to decide which tool we are going to build the pipeline with, and the landscape is broad and confusing: GitHub Actions, GitLab CI, Jenkins, CircleCI, Argo CD, Tekton... In the next lesson, Popular CI/CD Tools, we will draw the complete map of the ecosystem, look at what categories exist and how they genuinely differ, and justify why this course will use GitHub Actions as its main tool.