A pipeline is a machine you can read
It is Friday evening. The only person who remembers the deployment steps has gone home, and a colleague is staring at a terminal history. “Which command came after the database change?” Nobody is sure. Ada records the build, checks and deployment in a reviewed GitHub Actions workflow. It still needs owners and a recovery plan, but the next engineer can see the intended sequence and the evidence from its last run.
Classes 22–24 introduced pipelines in GitHub Actions. This part revisits the basic ideas before Class 39b shows how to express them in Azure DevOps. The tools use different names and syntax, but many pipelines can be understood by asking four questions: What starts the run? How is the software prepared? What checks are run? Where does the result go? That is a guide for reading a pipeline, not a claim that every pipeline uses the same steps.1
A release you can't repeat is luck.
A useful map: trigger, build, test, deploy
Use these four words as a map when you inspect a pipeline. A trigger is an event that starts a run, such as a code change, a schedule, or a button press. A build prepares the software, for example by compiling code or packaging files. A test checks some part of the software; teams choose which tests to run. A deploy puts software into an environment, such as a test site or the live production service. Teams configure their own steps and rules, so some pipelines skip steps, repeat them, or stop for a review.
When you read an unfamiliar pipeline, follow the steps and ask: What starts this run? What is produced? What checks happen before release? Where does it go? The answers help you understand the pipeline and spot missing checks. A test only blocks a later step when the pipeline is configured to stop on a failed test. In this course's example, that is the intended rule: test first, then deploy only when the required checks pass.
Play it through
Three minutes. Put trigger, build, test, and deploy in a sensible order for this example. Then try it again under pressure and see why the order matters. Real pipelines vary, but this practice run uses a test gate before release.
Three words that get confused daily
CI/CD is a short name people use for practices that automate building, testing, and releasing software. It can refer to three related ideas: continuous integration, continuous delivery, and continuous deployment. Teams sometimes use these terms differently, so ask how their actual release works if the distinction matters.3
- CI / CD
- Continuous integration (CI) means developers share code changes frequently and automate builds and tests so problems can be found earlier. Continuous delivery adds steps that keep tested software ready to release. A team may still choose when to release it to production.
In the common distinction taught here, continuous delivery keeps a tested change ready to release, while continuous deployment also sends it to production automatically after the configured checks pass. A human may approve a release in a delivery workflow; automatic deployment does not mean teams must remove every other safeguard. A company can add monitoring, staged rollouts, access controls, and ways to recover from a bad release. The important question is: what checks run, and who or what decides that a change reaches production?2
| Practice | What it automates | Reaches production… |
|---|---|---|
| Continuous integration | Frequently combine shared code changes and automatically build and test them | Does not by itself describe how software is released to production |
| Continuous delivery | Automate build, test, and preparation so software stays ready to release | A team can choose when to release; some releases include approval |
| Continuous deployment | Automatically release changes that pass the configured process | Production release happens automatically; monitoring and recovery still matter |
These practices often build on one another, but the labels alone do not tell you how a particular team has configured its pipeline. If someone says “we use CI/CD,” ask what starts a run, what checks must pass, and whether production deploys automatically or waits for a decision. That description is more useful than debating a label.
Why the machine pays for itself
A pipeline can give a team faster feedback. When a configured build or test runs after a code change, it can reveal a problem while the change is still fresh in the developer's mind. Finding a problem early often makes it easier to investigate because fewer changes have accumulated since then. The exact time saved depends on the project and on how useful its checks are.
Quick feedback can also encourage smaller changes. Smaller changes are often easier to review and troubleshoot than one large batch. Reverting a change may help, but it is not always simple: a database change or a change that affects stored data can need a separate recovery plan. Automation supports good team habits; it does not guarantee them.
A manual release can work well, especially for a small project. Its risks grow when instructions live only in one person's memory, there is no record of what changed, or no agreed way to recover from a failed release. A pipeline can record and repeat those steps, but the team must write useful instructions, configure checks, and plan recovery. Automation makes the process easier to inspect; it does not make a release risk-free.
The estate you are about to inherit
Fundamentals are worth learning because the first thing you meet on the job is rarely a blank page — it is someone else's machinery, working well enough that no one has questioned it in years. The skill this part gives you is not writing a pipeline from scratch; it is being able to look at what already exists, name the four boxes it has, and see the one it is missing. That reading skill is what turns a decade-old manual habit into a problem you can actually describe out loud — and the case file below is exactly that first encounter.
A warehouse release handled by hand
In this fictional example, Campux acquires Basecamp Outfitters and its Azure DevOps account. Thirty-one existing pipelines work, but a warehouse application is still released by hand: an engineer builds it on a computer, copies files to a server, and follows written or remembered steps. The team wants to understand that process before deciding what to change.
Use the four questions from Figure 1. Trigger: the release begins when someone decides to start it. Build: it happens on the engineer's computer, so another team member may not be able to repeat it easily. Test: the example does not mention a check before release. Deploy: a person copies the files to the server. Ask what record is kept and how the team would recover if the new version caused a problem. These are questions to investigate, not proof that the existing process has no safeguards.
Campux has acquired Basecamp Outfitters, a nine-store retailer with a warehouse system the whole business relies on. The engineering team has GitHub Actions workflows for most services, but the warehouse application is still built and copied to a server by hand each Friday. The goal of this track is to move that release into a workflow that builds, tests, and deploys the same reviewed artifact to Azure.
You are not asked to rebuild it this week. You are asked to read it. Lay the Friday-night ritual against the four boxes of Figure 1 and the gaps name themselves. The trigger is a human deciding it is Friday. There is a build, but it happens on one person's machine and nowhere else can reproduce it. There is no test gate whatsoever — nothing stands between a bad build and the warehouse floor. And the deploy is a manual copy with no record of what changed and no way back if it breaks. Written down like that, the work of the whole track stops being vague “modernisation” and becomes a punch list: give this deploy a trigger, a reproducible build, a real test gate, and a recorded deploy — in that order. Naming the missing shape is the first, and most senior, move you make.
Class 39 continues with YAML (39b), the computer that runs pipeline steps (39c), and ways to manage deployment access (39i). Before changing a real process, first understand what it does, what safeguards it already has, and what problem a proposed change would solve.
Carry the same build forward
In this part, do only the first workflow lab: green run, broken checkout, repair. Its continuation is a return task for after Parts E to H. When you come back, use the same disposable repository and artifact. The continuation gives you a failing content check, a skipped downstream job, checksum verification and an optional observable approval pause. Read the account prerequisites before claiming that a gate exists.
Examination
Four drills, then two situations. Try each drill before opening its explanation. The score shows your first attempt; the written situations are practice and are not graded.
B — a pipeline makes steps easier to repeat and inspect. A manual release can be faster for a small task, and a pipeline can still be poorly designed. Its advantage is that the team can save the steps, record each run, and choose checks to run before release. It does not remove the need to test or rely on a person's memory alone.
A — delivery prepares software so it is ready to release; deployment releases it automatically. In this lesson's common definition, continuous deployment sends changes that pass the configured process to production without waiting for a person to approve each release. Teams may use these terms differently, so in a real conversation ask what happens in their pipeline.
A trigger starts a run; an artifact is saved output; a deployment moves software to an environment. A team can configure a required test to stop a deployment when it fails. The pipeline follows its configured rules, so the existence of a test does not automatically make it a gate. A test environment also lets the team check software before production.
# plan: a real pipeline for the warehouse deploy
1. Trigger: run automatically on every push to the
main branch.
2. Build: compile once on the agent and produce a
single artifact.
3. Deploy that artifact straight to production, then
run the tests against it to confirm it worked.
4. Keep a human approval in front of the production
deploy.
Line three — run the required tests before the production deployment. In this example, the tests should check the build before it reaches customers. If a required test fails, configure the pipeline to stop before deployment. Building an artifact once and approving a production release can also be reasonable choices. A trigger can be automatic or manual, depending on what the team needs.
Start by understanding why the current method works. Six years without an incident is useful evidence. Ask the engineer to walk you through the release, including checks, records, and recovery steps. Then identify any risks the team wants to address, such as a process only one person can repeat or a lack of a documented recovery plan.
Propose a small, reviewable improvement. If the team agrees a pipeline would help, build it together and compare it with the existing release. Keep the experienced engineer involved: they know the system and can help check that automation preserves the important safeguards.
Make the comparison observable. Take one harmless change through the rehearsal pipeline. Ask the experienced engineer to check that it builds the same package, records the version and preserves the recovery steps. “Can another teammate repeat this release from the record?” is a useful question; “automation must be better” is not evidence. Adopt the improvement only after the rehearsal exposes what it does and what still needs a human decision.
Explain the common distinction taught here. "Continuous delivery keeps tested software ready to release; a team can still choose when to release it. Continuous deployment automatically sends a change to production after the configured conditions pass." Teams sometimes use these labels differently, so I would check how the pipeline actually behaves.
Then ask what controls the system needs. Payment software can affect money and private information, so the answer should account for the team's security, testing, monitoring, and recovery needs. An approval is one possible control, but it does not replace those safeguards. Some teams can safely deploy automatically when they have suitable checks and recovery procedures; others require a person to review a release.
Explain the conditions behind your choice. Describe which checks must pass, how a release is monitored, and how the team would respond if it caused a problem. That gives a reasoned answer without suggesting that a person or a test suite alone can guarantee safety.
Five things worth carrying out of this part
- A pipeline is a saved sequence of steps that runs on a computer and records its results.
- Trigger, build, test, deploy is a useful map for reading many pipelines. A real pipeline may add, skip, repeat, or conditionally run steps.
- A test blocks a deployment only when the pipeline is configured to require that test and stop if it fails.
- CI automates building and testing shared code changes. Delivery keeps software ready to release; deployment sends it to production automatically after configured conditions pass.
- When reviewing a release process, ask what starts it, what is produced, what checks run, where it goes, and how the team would recover from a problem.
- Trigger, build, test, and deploy are a teaching map used in this lesson, not a complete list of steps every product or pipeline must contain. Azure DevOps terms such as stages, jobs, steps, and tasks are introduced in Class 39b. ↩
- Teams may add approval, monitoring, staged rollout, access, and recovery controls to release pipelines. The delivery/deployment distinction in this lesson describes whether production release waits for a person or happens automatically after configured conditions pass; the labels alone do not describe the full safety design. ↩
- Microsoft describes CI as automatically building and testing code changes and continuous delivery as building, testing, and deploying to test or production environments. Its DevOps guidance distinguishes continuous deployment as automatically releasing updates that pass the pipeline. Teams can use the terminology differently, so check how a specific system behaves: Microsoft Azure Architecture Center: Get started with DevOps architecture and Microsoft Learn: Key Azure Pipelines concepts. ↩
- This lesson uses platform-neutral delivery concepts. GitHub Actions implementation details begin in Part 39b.
- The three-way split — integration, delivery, deployment — is the widely taught distinction, but usage in the wild is loose: plenty of teams say “CI/CD” or even “continuous deployment” for what is really continuous delivery with a manual approval in front of production. Do not correct people reflexively. Treat these definitions as the standard reference points, and in any given conversation resolve the ambiguity by asking the one question that actually settles it — is there still a human between a merge and a customer, or not. ↩
Explain workflow triggers, jobs, steps and runners, and find a failed step in a run log.
Play the lesson above to stamp this class.