A pipeline is the difference between shipping and hoping
Before there were pipelines, a release was a person. Someone built the app on their laptop, copied files to a server on a Friday night, ran a few things by hand, and hoped — and when it broke at eleven, only that person knew what they had actually done, and often not even them. A pipeline replaces that person with a machine you can read: a defined sequence — build the code, test it, deploy it — that runs the same way every time, records what it did, and refuses to skip the step that matters because it is late and everyone wants to go home. This is the discipline of continuous integration and continuous delivery, and it is the part of this bootcamp a team most needs a cloud engineer to own, because it touches every other part.
You met one CI/CD system already — GitHub Actions, across Classes Twenty-Two through Twenty-Four — and built real pipelines on it. This track teaches the same discipline on Azure DevOps Pipelines, and does it from the ground up rather than as a translation, because the concepts underneath — trigger, build, test, artifact, environment, approval — are not GitHub's or Microsoft's; they are the field's, and an engineer who understands them cold can walk into either system and read it on the first morning. Azure DevOps is not legacy: it is actively supported, deeply wired into Azure, and carries an enormous installed base of production pipelines — so the company that hires you may well ship on it, and the engineer who can speak both platforms is worth two who can only speak one.1
A pipeline you cannot diff is folklore.
The anatomy, drawn once — and the nine parts placed on it
Every pipeline, on every platform, is the same shape: a trigger starts it, a build turns source into a runnable thing, tests decide whether that thing is allowed to proceed, the result is packaged as an artifact, and a deploy carries that artifact into an environment — often through a human approval before production. The nine parts of this track walk that shape from left to right and then go under it: the first two teach what a pipeline is and how to write one; the middle four teach the machinery that makes it real at a company's scale — agents, variables, artifacts, environments; and the last three teach the judgement that separates a demo from production — how you release safely, how you gate on quality, and how you keep the whole thing from becoming your worst security incident.
- CI / CD
- Continuous Integration is the habit of merging every change into a shared main line often, each merge automatically built and tested so integration problems surface in minutes, not at the end of a quarter. Continuous Delivery is keeping that tested build always ready to release, on demand, through a repeatable deploy. The pipeline is the machine that makes both cheap enough to actually do.
The track — nine parts, first trigger to gated production
The rest of Class Thirty-Nine is nine pages, each a full class in its own right with its own drills, situations, and lab notes. Read them in order the first time — every part leans on vocabulary the earlier ones set, and the case file runs as one continuous story from the acquisition meeting to the credential that finally stops waking people at night. Later they work as reference: the page you reopen the week you actually inherit a pipeline estate, or the afternoon you finally add the test gate everyone agreed to and no one wrote.
- 39a · Pipeline fundamentals
- What CI and CD actually are, why pipelines exist at all, and the anatomy every one of them shares — trigger, build, test, deploy — plus the three words that get confused daily: continuous integration, continuous delivery, and continuous deployment.
- 39b · YAML pipelines
- The pipeline as a file in the repository: stages hold jobs hold steps and tasks; triggers and PR triggers; the implicit checkout; and a first working azure-pipelines.yml you can read end to end. Where your Class 22 skills get re-nouned.
- 39c · Agents & pools
- The machines that actually run the work: Microsoft-hosted versus self-hosted agents, pools and capabilities and demands, the parallelism grant, and the honest short list of reasons to take on a self-hosted agent's maintenance.
- 39d · Variables, parameters & templates
- How pipelines stay DRY and configurable: variables and their three evaluation clocks, typed parameters, variable groups linked to Key Vault, and templates — including extends, which is a security boundary, not just convenience.
- 39e · Artifacts & package management
- The thing you built, handed forward: pipeline artifacts between stages, Azure Artifacts feeds for NuGet and npm, upstream sources, and SemVer — versioning a package so the number itself tells consumers what changed.
- 39f · Environments, approvals & gates
- Where deploys land and who lets them through: deployment environments, manual approvals, and automated checks — the human gate before production, and the machine gates beside it.
- 39g · Deployment strategies
- Beyond deploy-and-pray: blue-green, canary, rolling, and ring-based release, plus feature flags with Azure App Configuration — separating the deploy of code from the release of a feature, so the two can fail independently.
- 39h · Testing & quality gates
- Making the pipeline say no: unit and integration test steps, published results and code coverage, quality gates that fail the build fast, and the discipline that keeps a green pipeline meaningful instead of decorative.
- 39i · Pipeline security
- The pipeline as an attack surface: service connections, OIDC workload identity federation, secret handling, least privilege, and the supply-chain basics — because the machine that can deploy to production is the most powerful credential in the building.
The posture that carries the whole track
Somewhere in the first month of a real job you will inherit a pipeline estate someone else built — dozens of them, some clicked together in a portal years ago, some already YAML, most undocumented — and two bad instincts will present themselves. The first is the crusade: rewrite everything, this quarter, to the modern way. The second is surrender: treat the estate as scenery, learn nothing, touch nothing, let it drift. The posture this track teaches sits between, and you can state it in three sentences. New pipelines are born as code in the repository, no exceptions. Existing pipelines convert when they are next touched — so effort lands only where change is already happening. And the riskiest credentials convert first, regardless of touch-order, because a stored, over-scoped secret in the deploy path is a standing liability whether or not its pipeline ever changes again.
That posture is the same one Class Twenty taught about infrastructure and Class Thirty-Six taught about recovery — respect the estate, price the change, do the thinking while nothing is on fire — and it is why the parts build in the order they do. You cannot secure a pipeline (39i) you cannot read (39b); you cannot gate on tests (39h) you never wrote; you cannot run a canary (39g) without the environments (39f) and artifacts (39e) beneath it. The track is one long argument that a delivery pipeline is not a script you dash off but a system you design — and the case file below is a company learning exactly that, one inherited pipeline at a time.
An acquisition arrives with thirty-one pipelines and one dangerous secret
Campux buys a smaller competitor — Basecamp Outfitters, nine stores, one warehouse system the whole business now leans on — and inherits its Azure DevOps organisation: Boards full of history, Repos full of code, and thirty-one pipelines that have shipped reliably since 2019. Some are clicked-together classic release pipelines; the warehouse deploy, the one that matters, is still done by an engineer copying build output to a server on Friday nights. Underneath all of them sits a single service connection named azure-prod — a stored client secret, scoped to the entire subscription, used by every pipeline in the org — and it expires in five weeks, which turns out to explain a recurring ticket in the acquired team's backlog titled simply "deploys broken again?? (monthly)".
This track is that first month, in order. Across the nine parts the reader gives the warehouse deploy a real pipeline (39a–39b), settles where it runs (39c), factors thirty-one near-identical pipelines down to a template (39d), moves Basecamp's internal packages off a file share into a proper feed (39e), puts a gated staging-to-production flow under the warehouse deploy (39f), gives the November storefront peak a canary and a feature flag (39g), adds the test gate the warehouse pipeline never had (39h), and — last and most important — replaces azure-prod with federated, resource-group-scoped connections that hold no secret at all, closing the monthly ticket forever (39i). The Basecamp engineers, who arrived braced to be told their decade of work was legacy, instead watch their estate get the same respect, the same audit, and the same guardrails as Campux's own — and two of them, unprompted, start reading this bootcamp from Class One.
Why this track pays for itself the day you are hired
Of everything in this bootcamp, the delivery pipeline is the artifact a hiring manager can inspect most directly, because it is the one that shows how you think when no one is watching. A pipeline reveals whether you test before you ship or after you are paged; whether a human approves the production deploy or a merge does it silently at 4pm on a Friday; whether your credentials are stored and hoped-over or federated and scoped; whether a bad release rolls back in a command or a night. Those are not preferences — they are the difference between an engineer a team trusts with production and one it does not — and every one of them is a decision you encode, visibly, in the parts of this track.
So treat the nine parts as an investment with a legible return. Each is a paragraph you can say in an interview and a task you can do on the job, and together they move you from "I can deploy my app" to "I own the road every change in this company travels on, and I can show you exactly where it is safe." The parts build the hands; the hub, below, rehearses the judgement they serve — because by the end of this track the tools are not the point. You are the person the team trusts to run the road.
Zoom out: a pipeline is a delivery system, not a script
A delivery pipeline shapes how a whole team works, not just how one commit ships. Systems thinking is the habit of looking past the box you just built to the loops, dependencies, and limits around it. Take a whiteboard and work these five prompts before the exam — and carry them into every part that follows.
Fast, green pipelines build trust, so people merge small and often — a reinforcing loop that makes delivery safer. Flaky tests do the reverse: red builds that "just need a re-run" teach everyone to ignore failures, until a real one slips through. Which loop is your pipeline currently training people into?
A deploy depends on agents, artifacts, service connections, and the order of its stages. Draw the chain: what has to be healthy for a release to reach production? A shared agent pool or an expiring service-connection credential is a dependency that fails quietly — until everything waits on it at once.
Lead time is set by the slowest stage, not the average one. Find the bottleneck — the ten-minute integration test, the approval that waits for a person, the single environment two teams queue for — because speeding up any other stage changes nothing until that one moves.
You parallelise the build to make it faster. It is — and now you exhaust the agent pool, hit an API rate limit, and two pipelines deadlock over the same environment. More concurrency solved the wait and created a new kind of contention. Name it before it names you at 5pm on a Friday.
At ten times the commits per day, what gives first — agent availability, queue time, or the one shared staging environment everyone fights over? Which is a matter of buying more agents, and which is a redesign of how environments and branches map to the pipeline?
The engineer who ships is asked "does it work?" The engineer who gets promoted is asked "and then what?" — and has already drawn the loop.
The road that code travels on
The whole loop is yours now: commit to production, reviewed and repeatable. You build the pipeline — tests, a gated environment, an approval, a deploy that runs the same way every time — so no one ships by clicking and every change is traceable. By the end of this track you are not learning the tools; you are the person the team trusts to run the road that code travels on.
Examination
Four drills, then two situations. These test the judgement the track is built on; the hands are built across the nine parts. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B — the value is repeatability and a record, not speed. The laptop deploy is sometimes genuinely faster on the day; what it cannot do is run identically next Tuesday when a different person does it, prove what it actually ran, or refuse to skip the test step at eleven at night when everyone wants to go home. D is the seductive wrong answer — "if the person is careful" is exactly the single point of failure a pipeline exists to remove, because people are careful right up until the one Friday they are not, and that Friday is the outage. A invents a speed guarantee that does not hold, and C inverts the discipline the whole track defends: the pipeline is where tests run, not a substitute for them. The pipeline replaces a fragile person with a legible machine.
B. Trigger starts it, build turns source into a runnable thing, tests decide whether it proceeds, the artifact is the packaged result, and the deploy carries it into an environment — with a human approval commonly guarding production. C is Class Thirty-Six's incident loop, a different machine for a different day; recognising that it is not the pipeline shape is part of knowing this one. D is the belief that keeps new joiners from reading an inherited pipeline for three weeks: the tools differ in their nouns, but the shape is the field's, which is exactly why learning it on one platform makes you fluent on the next. Draw the five boxes until they are reflex; every part of this track hangs off one of them.
New pipelines born as code, riskiest credential first, existing ones convert when touched. Those three are the whole posture: stop the hole deepening, de-risk the estate where it is most dangerous, and let effort land only where change is already happening. The two rejects are the two crusades the track names. Rewriting thirty-one working pipelines in a quarter is a project with real regression risk, zero feature output, and a success state invisible to everyone outside engineering — the exact shape of initiative that dies at week eight, half-migrated, worse than either end state. And leaving the estate as scenery lets the click-drift compound and surrenders the review seat at the moment fresh eyes are worth the most. Neither crusade nor surrender; the measured middle you can state in three sentences.
# my plan for the inherited pipelines
1. Learn to read one pipeline end to end before I
change any of them.
2. Lock down pipeline security first — federate every
service connection this week — then worry about
whether the pipelines even have tests or gates.
3. Add the missing test gate to the warehouse pipeline
when I next touch it for a real change.
4. Give the November storefront peak a canary and a
feature flag before it arrives, not during it.
Line two — and the tell is the word "then". Federating credentials first is genuinely right and matches the posture (riskiest credential first). The error is the second half: treating a locked-down credential as if it made the tests and approval gates optional or secondary. A pipeline with a perfect federated identity and no test gate still ships broken code to production the moment someone merges it — the credential controls who can deploy, not whether what they deploy is any good. Security, quality gates, and approvals are three independent controls that sit beside each other; none substitutes for another, and "worry about that later" is how a pipeline ends up impeccably authenticated and completely untrustworthy. The other lines are the plan at its best: read before you change (A inverts it), add the gate when you touch the pipeline (C is §4's convert-when-touched), and price resilience before the peak, not during it (D inverts it — the whole point of 39g is doing it while calm).
The trap is answering the question as asked, because the option it offers is a crusade. Thirty-one working pipelines rewritten in a quarter is a project with real regression risk, zero feature output, and a success state invisible to everyone outside engineering — the exact shape of initiative that gets cancelled at week eight with a third of the estate half-migrated, worse than either end state. Decline it politely — but do not waste the manager's energy, because a manager offering budget for pipeline hygiene is rare weather. Redirect it.
Give them the §4 posture with a risk-ranked first target. New pipelines born as code, from today, as policy — free, immediate, and it stops the hole deepening. Existing pipelines convert when touched, so effort lands only where change already happens. And the budget goes to the one thing worth doing proactively: the credential audit — enumerate every service connection, find the stored, subscription-scoped ones (there will be at least one, used by everything), and replace them with federated, resource-group-scoped connections. That work is invisible in a demo and priceless in an incident, it de-risks all thirty-one pipelines at once without rewriting any of them, and it produces a number for the manager's slide: "standing secrets in the deploy path: was one, shared by thirty-one pipelines; now none."
Close by giving the conference its due, so the manager keeps their win. The instinct is right — the estate should trend toward pipelines-as-code; the correction is sequencing, not direction. Offer the milestone version: this quarter, the audit plus the top three riskiest pipelines converted; next quarter, reassess with data. The sentence for the meeting: the pipelines aren't the risk — the credentials under them are, and fixing credentials doesn't require touching a single pipeline that works.
Name the shape before the steps, so they know you are not improvising. "It travels a pipeline, and the pipeline is always the same shape." Then walk it: the merge is the trigger; the build turns the source into an artifact once, so the exact thing tested is the exact thing shipped; the tests run and the pipeline refuses to proceed if they fail — that is the whole point, the machine says no so a tired human doesn't have to. The tested artifact is published, and deployed to staging automatically.
Then put the human gate where it belongs and mean it. "Production is a separate environment with an approval — a named person confirms, so no single merge silently reaches customers at 4pm on a Friday. The deploy itself is a strategy, not a leap: I'd roll it out to a slice first — a canary — watch the signals, and roll back in a command if they're bad. And nothing in that pipeline holds a stored secret; it authenticates to Azure with a federated identity scoped to just the resource group it deploys to." Five boxes, one gate, one safe rollback, one scoped credential.
Close on what the shape reveals about you. "The reason I answer it as a shape rather than a tool is that it's the same shape on Azure DevOps or GitHub Actions — I've built it on both. What's portable isn't the YAML dialect; it's the decisions: test before ship, a human before production, a credential that's scoped rather than trusted, a rollback that's one command." That reframes you from "person who knows one tool" to "engineer who owns delivery" — and it is simply true, which is why it survives the follow-up questions. That is the method of this whole bootcamp: the gap was never the missing noun; it was the proof, and now you carry it.
Five things worth carrying out of this hub
- A pipeline replaces a fragile person with a legible machine: a defined sequence that runs the same way every time, records what it did, and refuses to skip the step that matters because it is late. That is the whole value — repeatability and a record, not speed.
- Every pipeline shares one shape: trigger, build, test, package as an artifact, deploy to an environment through an approval. The nine parts of this track are that shape, elaborated and taught in order. Draw it until it is reflex.
- CI is merging often with every change built and tested; CD is keeping that build always ready to release through a repeatable deploy. The pipeline is the machine that makes both cheap enough to actually do.
- The discipline is platform-independent. Learn it here on Azure DevOps and you can read GitHub Actions on the first morning, and vice versa — because the nouns differ but the shape is the field's.
- Meeting an inherited estate: new pipelines born as code, existing ones convert when touched, riskiest credentials convert first regardless. Neither crusade nor surrender — the same migration posture Class Twenty and Class Thirty-Six taught, applied to delivery.
- Treat any specific market-share claim about Azure DevOps versus GitHub with suspicion — the numbers are argued about and change yearly; the direction is settled in both halves: an enormous installed base still ships on Azure DevOps, and net-new investment flows toward GitHub. Both halves matter to your career, which is precisely why this track teaches the platform-independent discipline first and the Azure DevOps nouns second. Read the current positioning before repeating anyone's prediction of the platform's demise, including one you infer from this page. ↩