The previous five lessons were labs: every step was written down, every file was handed to you and every failure was anticipated. This one is not. This one is the brief. Here you have a company context, a set of constraints, a budget and a list of requirements with their acceptance criteria, and from there you decide: which tool, which deployment strategy, which tests to write first, which scans to run on every PR and which only on main, where to put the gates, what to leave out and —hardest of all— how to justify each of those decisions to somebody who was not there when you took them.

You can do it on a project of your own (better, if you have one) or on Mini-Reservalia. What you cannot do is copy the pipeline from 07-05 as it stands: the brief's context has constraints that force you to deviate from it in at least three places, and finding them is part of the exercise.

1. The brief
2. The context: Citas Norte, S.L.
3. Mandatory requirements and acceptance criteria
4. Deliverables
5. Self-assessment rubric
6. A work plan in five sessions
7. Optional challenges
8. Typical mistakes in the final project
9. Common Mistakes and Tips
10. Exercises
11. Conclusion and closing the course in practice

You join a small company as delivery lead. It has a product in production and no pipeline at all. They deploy by hand, they never deploy on Fridays, and the last time something went wrong it took them two hours to go back because nobody remembered which version had been running before.

Your brief: take that product from its current state to a complete end-to-end pipeline, with quality gates, an immutable artifact, automated deployment with rollback, and metrics that prove the situation has improved.

The condition of the brief: everything you build has to be verifiable by an external reviewer who has never spoken to you, in less than an hour, looking only at the repository.

That last condition is what turns the exercise into something close to real work. A pipeline that only works when you are standing there to explain it is not a deliverable: it is a dependency.

Constraints are what force decisions to be justified. If everything were possible, there would be nothing to decide.

The company. Citas Norte, S.L. sells booking software for small businesses. It has:

The constraints, which are non-negotiable:

1. Tooling budget: €0/month. The company is approving no new spending until the next financial year. Everything has to fit into free plans.
2. Nobody can be dedicated to operating the pipeline. The team is three people and all three are 100% on product. A self-hosted Jenkins is ruled out because of this, not for technical reasons.
3. The current maintenance window is sacred to the business: on Saturday mornings, between 9:00 and 13:00, 40% of the weekend's bookings are concentrated. Downtime there costs customers.
4. There is personal data (name, phone number and email of the end customers of those 180 businesses). Any leak is a reportable incident.
5. The tech lead goes on holiday for three weeks in two months' time. During that period, the other two people have to be able to deploy and roll back without her.
6. The team distrusts automation. The backend developer, specifically, has said in so many words: "every minute we spend on this is a minute we are not spending on what we get paid for". Your proposal has to pay off quickly and you have to be able to prove it with numbers.

Three consequences of reading the constraints properly (check them against your decisions when you finish):

• Constraints 2 and 6 together rule out any solution requiring ongoing maintenance. Fewer pieces and more standard beats more powerful.
• Constraint 5 means the rollback has to be executable by somebody who did not write it, with one button and without remembering commands. Documenting is not optional here: it is a functional requirement.
• Constraint 3 does not mean "deployment windows". It means that time to restore matters more than frequency. If you can revert in 3 minutes, Saturday stops being frightening; if you take 2 hours, no window will save you.

The baseline you have to measure before touching anything (it is the most frequently skipped requirement in the whole project):

Every requirement comes with its verifiable criterion. The formula "an external reviewer must be able to check that…" is deliberate: if it cannot be checked by looking at the repository and its runs, it does not count.

Total: 29 requirements. Nobody expects all of them to be immaculate; what is expected is that all of them have been considered and that the absences are documented decisions, not oversights.

Public (or private with access for the reviewer), with a real history: branches, PRs, checks, successful runs and failed runs. A repository with a single giant commit does not demonstrate a pipeline; it demonstrates a file.

Suggested structure:

This is the deliverable that shows the most and that is done the worst. It is not documentation of what the pipeline does —that is readable in the YAML—: it is the record of why it is the way it is and what was sacrificed.

Minimum template:

The "What we have NOT done and why" section is what separates professional work from an exercise. A pipeline with no explicit limits is a pipeline that will grow uncontrollably until somebody abandons it.

Cause a real failure, let it travel as far as your pipeline stops it, and write the post-mortem. Suggested failures, in order of difficulty:

The structure of the post-mortem, blameless:

A versioned Grafana dashboard, or —if you do not set up Prometheus— a $GITHUB_STEP_SUMMARY from a scheduled job with the four DORA metrics, the SLO status and the error budget consumption. What is being assessed is that there is a surface where somebody who is not you can see how things are going without having to ask you for anything.

Apply it to yourself honestly. The "Inadequate" column describes what most people deliver on their first attempt.

How to score yourself: count how many rows fall into each column.

• Mostly in Inadequate: you have a pipeline that works but is not defensible. Prioritise group A and B4/B6.
• Mostly in Solid: this is a professional, deliverable pipeline. It is the realistic objective of the course.
• Several in Excellent: you are above what many teams in production have. Pick two or three to take to excellent rather than raising them all at once.

Five sessions of 2-4 hours. The order is not arbitrary: each session leaves something working and measurable, and none of them depends on finishing the next one to deliver value. It is the same principle as the seven increments in 05-04.

1. Measure the baseline. The four DORA metrics with whatever data you have, even if approximate. Write them into PIPELINE.md today, because in three weeks you will not be able to reconstruct them.
2. Get the project verified with a single command: npm ci && npm run lint && npm test && npm run build. If that does not work on a clean machine, fix it before writing a line of YAML.
3. Write the missing test for the most recent bug you had.
4. Commit the lockfile if it is not there.

Session deliverable: one command that verifies the project, and the baseline written down.

1. ci.yml incrementally, as in 07-01: first get it to run, then get it to install and test, then jobs in parallel, then caching. Measure the times at each step and note them down.
2. The three layers of tests (07-02). Start with the one you are most afraid of breaking.
3. Coverage with a threshold 2-3 points below the current value.
4. Protect main with an aggregator job as the only required check.
5. Break something on purpose and check that it blocks.

Deliverable: A1-A6 met, with the before/after times for the cache.

1. Multi-stage Dockerfile, non-root, HEALTHCHECK (07-03).
2. Publication to the registry by digest, with the digest visible in the summary.
3. scripts/deploy.sh, idempotent and runnable locally. Write it before the YAML: if you start with the YAML, you will end up with logic inside the YAML.
4. scripts/smoke.sh checking health, functionality and version.
5. cd.yml with two environments and approval on the second.
6. rollback.yml, timed. Run it and note the time.
7. Cause a bad deployment and check that the smoke test stops it.

Deliverable: B1-B7 met, with the timed rollback run and the blocked deployment run.

1. An audit of what you have built so far, using the list from 07-05.
2. Least-privilege permissions, provoking a failure to understand it.
3. Actions by SHA + Dependabot.
4. The five scans, one at a time, checking that each one detects something real before moving on to the next.
5. A written severity policy and the exception expiry job.
6. SBOM, signature and verification before deploying.

Deliverable: D1-D6, with evidence that each scan has detected something.

1. /metrics with the golden signals (07-04).
2. An SLO with the budget arithmetic written out.
3. A symptom-based alert, fired on purpose and with a screenshot.
4. A scheduled DORA job. Run it twice a few days apart so you have a trend.
5. Cause the post-mortem failure and write it up.
6. A complete PIPELINE.md, including the section on what you have not done.
7. Take the rubric.

Deliverable: E1-E5, PIPELINE.md, POSTMORTEM.md and the self-assessment.

A word on pacing. If you are short of time, sacrifice group E before group B. A pipeline that deploys and reverts but is not measured is incomplete; one that is measured but cannot revert is dangerous. And if you have to pick a single requirement out of the 29, make it B6: a timed rollback. It is the one that turns fear into a number.

For once the basics are closed off. Each one stands on its own.

The most instructive of all, if you want to close the course with something that changes your perspective, is the matrix of two tools: reimplementing the pipeline in GitLab CI forces you to separate what is your process from what is GitHub syntax, and that separation is exactly what 06-07 was arguing for. It takes less time than it looks —the real work is already in the scripts— and the result is an equivalence table you wrote yourself.

These three are, by a distance, the most repeated. All three have the same shape: doing the visible part before the part that holds it up.

How it shows up. You open ci.yml and start typing. Three days later there are 200 lines of YAML with twenty-line run: | blocks each, and the only way to test a change is to push and wait four minutes.

Why it matters. The debugging cycle goes from seconds to minutes, and multiplied by every attempt. A problem that locally takes five ten-second iterations turns into five four-minute iterations, with commits saying "fix CI", "fix CI 2", "now for real". On top of that, that logic is not testable, not reviewable, and cannot be run in an emergency if CI is down.

The right order:

The acid test: can you deploy without GitHub Actions? If the answer is no, the logic is in the wrong place.

How it shows up. A beautiful pipeline that deploys in ninety seconds... broken code. The tests exist, they always pass, and they cover none of what actually breaks.

Why it matters. Automating deployment multiplies the speed at which changes reach production. If the verification is weak, what you have multiplied is the speed at which bugs reach production. A fast pipeline on top of bad tests is objectively worse than the manual deployment you started with, because the manual one at least involved a person looking.

The right order: a test that catches the last real bug you had, before automating the deployment. If you cannot write it, do not automate yet: automate only as far as staging and leave production manual until the safety net exists.

The warning sign: if your suite has never gone red because of a real bug —only because of syntax errors— it is not testing anything.

How it shows up. Three weeks of work, an excellent pipeline, and then in the meeting with management: "so what has this improved?" — "Well... everything is much better".

Why it matters. It is the mistake that stops the next investment being approved. Remember constraint 6 of the context: the backend developer already thinks this is time stolen from the product. Without numbers, he is right, because his scepticism is based on something concrete (the hours invested) and your defence is not.

And there is a technical aggravating factor: the baseline cannot be reconstructed after the fact. Once the pipeline is in place, the "before" no longer exists. It is information destroyed by doing the work.

The right order: measure in session 1, before touching anything, even with rough estimates. Four numbers and the date. Ten minutes of work that pay for the next three weeks.

How you present it afterwards:

That last row is the one that ends the discussion, and that is why it is worth having: it translates the work into person-hours, which is the unit whoever approves budgets thinks in. It is exactly the TCO argument from 06-07, applied to your own project.

Symptom: the project gets stuck in session 3 and never reaches production. Cause: trying to set up the "real" target environment (a VPS, Kubernetes, AWS) before having the pipeline. Fix: use a simulated target like the one from 07-03 and complete the whole circuit. A pipeline that deploys to a local container but covers the seven pieces of B1-B7 is worth infinitely more than half a pipeline pointing at real infrastructure. Change the target at the end; it is the easiest part to change.

Symptom: 29 requirements look unmanageable and you never start. Cause: trying to do them in parallel. Fix: the five-session plan is ordered by dependency. Finish A completely before touching B. One finished group is worth more than five half-done ones, because incomplete groups cannot be verified.

Symptom: the PIPELINE.md ends up being a description of the YAML. Cause: documenting while writing the code, when there is still no perspective. Fix: write each decision down at the moment you discard an alternative, in one line: "discarded X because Y". By the end, those lines are the document. If you never discarded anything, you did not make decisions: you copied.

Symptom: the rubric comes out mostly in "Solid" and you do not know what to improve. Tip: do not push everything to "Excellent". Pick two or three deliberately: the ones that most reduce risk in your specific context. With Citas Norte's constraints, the three obvious candidates are the rollback (constraint 5), the signature verification (constraint 4, personal data) and DORA with a trend (constraint 6, somebody has to be convinced).

Tip — do not do it all yourself. If you have somebody available, ask them to verify your repository following the acceptance criteria, without you explaining anything. The points where they have to ask you something are exactly the ones you still need to document. It is the cheapest and most revealing test in the project.

Tip — the pipeline is never finished. When you close all 29 requirements, the pipeline will be good for today's context. With twice the team and ten times the traffic, three of your decisions will be wrong. That is why every decision in the PIPELINE.md carries a "when to revisit this decision": it is not bureaucracy, it is acknowledging that a pipeline is a living organism and that the alternative to revisiting it is rewriting it entirely two years from now.

These three are not lab variations: they are extensions of the final project itself, designed to be done after delivering it.

Swap repositories with somebody else who has done the project (or audit a real public repository that uses GitHub Actions). Apply the 29 acceptance criteria without talking to anyone and write an audit report with the findings prioritised.

Constraint 5 of the context: the tech lead is away for three weeks. Prove the system survives.

Halve your pipeline's time without removing a single check. Document every change with its measurement.

Solution 1. Audit report template:

What this exercise teaches: auditing somebody else's work is the fastest way to see the holes in your own. Almost everybody finds two or three things in the other repository that their own is missing too and that they had not spotted in weeks.

Solution 2. The protocol for the test:

The three failures that show up almost every time in this exercise, in case you want to get ahead of them:

1. Finding the previous digest. Nobody knows where to look. Fix: print it in the summary of every deployment and accept an empty input in the rollback (07-03 exercise 1).
2. The alert reached nobody. It was configured in Prometheus but had no recipient. Fix: Alertmanager with a real channel, and proof that it arrives.
3. The manual path does not exist. All the knowledge is inside the YAML. Fix: scripts/deploy.sh runnable locally (requirement C2), documented in the runbook with the literal command.

If your project passes scenario 3, you have met the most demanding criterion in the whole course: the pipeline is a convenience, not a dependency.

Solution 3. The strategy, in order of return:

The lesson of this exercise is C3: the Docker cache does not work if the Dockerfile is badly ordered, and plenty of people add C2, see no improvement and conclude that "caching is useless". Layer ordering is 80% of the result, and it is free.

If you have got this far with the project delivered, you have something in your repository that many teams in production do not have: a pipeline that integrates, verifies in three layers, builds an immutable artifact identified by its content, scans it in five different ways, signs it, deploys it behind an explicit gate, checks that the deployment worked, promotes the very same artifact without rebuilding it, reverts in minutes —on its own, if the metrics get worse—, and measures itself so it can prove that all of that is worth something.

But the deliverable that will last longest is not the YAML. It is the two documents.

The PIPELINE.md, because it contains the one thing you cannot deduce by reading the code: why it is the way it is and what was sacrificed in return. A year from now, when somebody —perhaps you— wonders why there is no canary or why the actions are pinned to those strange SHAs, the answer will be written down, with its date and with the condition that would force a review. A pipeline without that document gets rewritten from scratch every two years because nobody dares touch what they do not understand.

And the POSTMORTEM.md, because it documents the only proof that really matters: that the system failed and held up. Anybody can show you a pipeline in green. Showing one that went red for the right reason, in the right place, and recovered in three minutes, is showing that it works.

There is one last thing this module has made you do without saying so explicitly, and it is worth naming now. In every lab you have broken something on purpose: a test, a deployment, a secret, a SQL query, a slow endpoint. That was not pedagogical decoration. It is the professional practice that separates whoever has a pipeline from whoever trusts their pipeline: verifying from the negative side. Anybody can check that a control lets the good stuff through; checking that it stops the bad stuff requires manufacturing the bad stuff, and almost nobody does it. If you take a single habit away from this course, let it be this one: every time you add a gate, cause the failure it is supposed to stop, and do not take the gate as good until you have watched it happen.

That closes the practical part and, with it, the taught material of the course. You have covered the principles (modules 1 to 4), four real contexts (module 5), the machinery (module 6) and end-to-end construction with your own hands (module 7). What remains is no longer material: it is where to go next.

Module 8 is the map of that continuation. The recommended reading —Continuous Delivery, Accelerate, The DevOps Handbook, the SRE Workbook— that provides the grounding and the data behind almost everything you have applied here. The communities and forums where these problems are discussed once they outgrow what fits in a course. The additional tools and plugins that were left out for space and that solve specific problems you will now be able to recognise: secret management with Vault, progressive delivery with Flagger or Argo Rollouts, internal developer platforms, policy as code. And the learning path and certifications, with a sensible order for going deeper depending on where you want to move —platform, SRE, supply chain security— and which certifications are genuinely worth it in each case.

Start with 08-01: Recommended Reading. And when you do, read it with the pipeline in front of you: you now have a real system to try every idea on, which is exactly what was missing the first time you opened this course.