A pipeline is the difference between shipping and hoping
Imagine two people deploying the same change by following different notes. One forgets a test; the other uploads the wrong build. A pipeline puts the steps in a versioned configuration file and runs them in a controlled order: build, test, package, and deploy. The run records its results, and you can configure it to stop when a required check fails. Versioned steps and controlled dependencies make runs more repeatable; they do not guarantee every run succeeds. This is the practical work behind continuous integration and continuous delivery.
You have already used GitHub Actions in Classes 22–24. Class Thirty-Nine extends that foundation into a complete production workflow: event filters, build and test jobs, artifacts, environment protection, release strategies, and secure Azure deployment with OIDC. The Azure services remain the deployment target; GitHub Actions is the only pipeline system taught in this track.
Keep pipeline steps where the team can review them.
The anatomy, drawn once — and the nine parts placed on it
A useful starting model is: a trigger starts a run, a build prepares the code, tests check it, the result may be packaged as an artifact, and a deploy sends it to an environment. A team may add approvals or automated checks before production. Real pipelines can skip or repeat stages based on their configuration, so use this as a map rather than a rule that every pipeline has the same steps. The nine parts build from the basic shape to agents, variables, artifacts, environments, release strategies, tests, and security.
- CI / CD
- Continuous Integration (CI) means frequently combining code changes and automatically building and testing them so problems surface early. Continuous Delivery (CD) keeps a tested build ready for a controlled release when the team chooses. Continuous Deployment goes a step further: qualifying changes are automatically released to users. A pipeline can support these practices when its triggers, tests, and release steps are configured to do so.
The track — nine parts, from first trigger to release controls
Class 39 has nine lessons, each with explanations, drills, situations, and lab notes. Read them in order first because later lessons use earlier terms. After that, return to the relevant lesson when you are writing or reviewing a pipeline.
- 39a · Pipeline fundamentals
- What CI and CD mean, why teams automate changes, and the shared shape: an event starts a workflow, jobs run build and test steps, and a protected deployment can release the result.
- 39b · The workflow file
- Read and write a complete GitHub Actions workflow: events, jobs, steps, permissions, artifact handoff, and a protected Azure deployment using the OIDC identity from Class 23.
- 39c · Runners & groups
- The machines that execute jobs: GitHub-hosted and self-hosted runners, labels and runner groups, plan-dependent limits, and when the maintenance of self-hosting is justified.
- 39d · Variables & reusable components
- Use GitHub contexts, variables, secrets, reusable workflows, and composite actions. Learn what can be shared safely and what repository rules are needed to enforce it.
- 39e · Artifacts & package management
- The build passed between jobs as an Actions artifact, then GitHub Packages for versioned NuGet and npm packages, package access, and SemVer — versioning a package so the number itself tells consumers what changed.
- 39f · Environments & approvals
- Use deployment environments to add reviewer and branch controls, and understand which protections must be configured in GitHub settings outside the workflow file.
- 39g · Release strategies
- Plan blue-green, canary, rolling, and ring releases with Azure App Service, AKS, or a traffic layer; GitHub Actions coordinates the steps while the platform changes traffic.
- 39h · Testing & quality gates
- Run tests, retain reports and coverage, and make required checks block unsafe merges so a green workflow carries useful evidence.
- 39i · Workflow security
- Limit the GitHub token, use OIDC to Azure, protect production environments, handle secrets safely, and review the actions and dependencies each workflow executes.
The posture that carries the whole track
When you inherit a pipeline estate, start by understanding what each pipeline does and which resources it can change. For new pipelines, YAML in the repository is a strong default because the team can review and version its configuration. Where workflows already exist, inspect what they change, what identity they use, and how deployment is protected. Convert manual releases in small steps: validate the build and test first, then deploy a known artifact using OIDC and least-privilege Azure permissions.1
This is similar to the approach in Class 20 for infrastructure and Class 36 for recovery: understand the existing system, estimate the risk, then change it in manageable steps. The lesson order follows those dependencies: learn to read a pipeline before securing it, define tests before adding a quality gate, and understand artifacts and environments before choosing a deployment strategy.
An acquisition arrives with thirty-one pipelines and one dangerous secret
This is a fictional example. Campux acquires Basecamp Outfitters and inherits 31 GitHub Actions pipelines. Some workflows exist, but the warehouse deployment still copies files by hand. A federated identity named azure-prod has broader Azure permissions than the warehouse needs and has not been reviewed recently. That creates both a security risk and a predictable maintenance task.
The nine lessons build a plan: create a repeatable warehouse pipeline, decide where it runs, reuse common configuration, publish internal packages, protect deployments with environment checks, choose a release strategy, add tests, and review credentials. For the Azure connection, consider workload identity federation to avoid storing a long-lived secret, then grant only the Azure permissions the pipeline needs. Federation removes secret rotation for that identity; it does not remove the need to secure the identity and its Azure role assignments.2
Why this track pays for itself the day you are hired
A pipeline is one artifact a hiring manager can inspect to understand how you approach software delivery. It can show which tests run, how production is protected, how Azure authentication works, and what recovery steps exist. Those protections depend on the pipeline and resource settings; YAML alone does not make a release safe. The nine lessons explain how to make those choices visible and testable.
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, reliable test results help teams merge small changes often. Flaky tests can train people to rerun or ignore failures, making it easier to miss a real problem. What behavior do your pipeline results encourage?
A deploy depends on runners, artifacts, federated identities, and job dependencies. Draw the chain: what has to be healthy for a release to reach production? A busy runner group, missing artifact, or stale OIDC trust rule can stop every deployment at once.
The slowest required step often limits how quickly a change reaches production. Look for a long test, an approval that waits for a person, or a shared environment with a queue. Improving a faster step may not reduce the total wait until the bottleneck changes.
Running more jobs at once can shorten a build, but it can also use all available agents, hit an API limit, or make deployments wait for a shared environment. Check the queues and resource limits before increasing parallel work.
If commit volume grows, monitor agent availability, queue time, and shared test environments. More agents can help with a capacity shortage; long waits for one shared environment may need a change to how teams schedule or isolate deployments.
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
By the end of this track, you can follow a GitHub Actions workflow from event to deployment, explain where tests and release controls belong, and identify the GitHub and Azure settings that make them work.
Examination
Four drills, then two situations. The drills check key ideas; the nine lessons build hands-on skills. The situations have no single marked answer: write your response first, then reveal the reasoning and compare it with your own. Nothing is stored.
B — a pipeline can run the same configured steps and record the result. A laptop deploy might be quicker for one person on one day, but it is harder for the team to review and repeat. The pipeline can be configured to stop if a required test fails; it does not do that automatically unless the test and failure condition are included. C is wrong because a successful deployment does not prove the code passed tests. D overlooks the value of a shared, reviewable process.
B. In this example, a trigger starts the run, a build prepares the code, tests check it, an artifact packages the output, and a deployment sends it to an environment. A production approval is one possible control, not a required step in every pipeline. C describes incident response. Actual pipelines vary, but this flow is a useful way to organize the concepts in this track.
Options two, four, and five. YAML in the repository is Microsoft's recommended starting point for new pipelines, while an exception can make sense for a specific feature or source system. Audit federated identities separately and prioritize broad or long-lived credentials. Migrate existing pipelines when there is a reason and a safe plan. A blanket rewrite creates avoidable work and risk; ignoring the estate leaves unknown dependencies and permissions unreviewed.
# my plan for the inherited pipelines
1. Learn to read one pipeline end to end before I
change any of them.
2. Replace the stored credential with workload identity
federation; that alone proves each release is safe,
so tests and approval checks are unnecessary.
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 confuses authentication with release quality. Workload identity federation can remove a stored secret from the Azure connection, but tests check the code and approval checks control when a protected deployment stage can run. Configure all three controls when the risk calls for them. Line one is a sensible first step, line three adds a test gate during a planned change, and line four prepares for a predictable traffic peak.
Start with discovery, then compare the cost and risk. A blanket rewrite can interrupt working releases and consume time that could address higher-risk problems. First document what each pipeline deploys, who owns it, what permissions it uses, and how it can be recovered.
Recommend a staged plan. Use YAML in the repository as the default for new pipelines, while recording exceptions. Review federated identities and prioritize broad or expiring credentials, regardless of whether their pipeline is due for migration. Migrate existing pipelines when they change or when the security, support, or maintenance benefit justifies a planned conversion.
Set a measurable first milestone. For example, review all federated identities, reduce permissions on the highest-risk connection, and migrate one representative pipeline with rollback steps documented. Then review the result and choose the next set based on evidence.
Describe one configured delivery flow. "A merge trigger starts the pipeline. It builds and tests the code, publishes a versioned artifact, then deploys that artifact to staging. I make sure production receives the same artifact that passed tests, rather than rebuilding different bits for each environment." Triggers and artifact promotion must be configured, so explain the setup you actually used.
Explain the production controls. "For production, I can protect the environment with approval and other checks. If the change is suitable, I might use a canary and monitor it before widening release. I plan how to roll back the application and any data changes. For Azure authentication, workload identity federation can avoid storing a long-lived client secret; I still scope Azure permissions to what deployment needs." Approvals, canaries, and rollback mechanisms must be configured and tested.
Then connect it to your experience. Explain which parts you have actually built on GitHub Actions. Explain what you personally configured: the workflow trigger, test gate, artifact, OIDC trust, and production protection. Give a concrete example of a failed check or rollback you handled.
Five things worth carrying out of this hub
- A pipeline stores steps in a reviewable configuration and records each run. Required tests and checks must be added and configured; a pipeline does not enforce steps you leave out.
- A useful delivery flow is trigger, build, test, package, and deploy. Stages and approvals depend on the pipeline's purpose and configuration.
- 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.
- GitHub Actions is the only pipeline system taught in this track. Check the current GitHub Actions and Azure documentation for syntax, limits, and deployment behavior.
- For an inherited estate, learn the workflows first, prefer YAML for new pipelines where it fits, plan existing migrations for a clear benefit, and review high-risk credentials early.
- GitHub Actions workflows and environments use repository settings and the workflow permissions model. Confirm available environment protection rules and billing limits for the repository plan and visibility.
- Microsoft recommends workload identity federation for Azure Resource Manager federated identities to avoid managing secrets. Azure role assignments still determine what that identity can do. ↩
Explain a GitHub Actions release path from reviewed change to checked artifact, environment protection and Azure deployment.