Contoso's main branch is already protected by policies, but one of them points at nothing: build validation requires a pipeline to give the go-ahead before merging, and that pipeline does not exist yet. Without it, the other policies check formalities — there are two approvals, there is a linked work item — but nobody has verified the most elementary thing: that the code builds and that the tests pass.

This lesson builds that verifier. Azure Pipelines runs, on every proposed change and every merge, the same repeatable sequence of restore, build, test, analyze and package. The result is an artifact — the exact package that will later be deployed — and a binary verdict within a few minutes. Here we deal only with building and verifying; taking that artifact to Azure is the next lesson.

1. What continuous integration is and what problem it removes
2. Agents, pools and their real costs
3. YAML pipelines versus classic UI ones
4. Anatomy of an azure-pipelines.yml, line by line
5. The essential tasks and dependency caching
6. Variables, variable groups and Key Vault
7. Reusable pipeline templates
8. Pull request validation and job matrices
9. Artifacts, failure diagnosis and the status badge
10. Common Mistakes and Tips
11. Exercises
12. Conclusion

Continuous integration means that every change is integrated with everybody else's work and verified automatically, several times a day. It is not "having a build server": it is a discipline in which everyone's code is constantly brought together instead of piling up in separate corners.

The problem it removes has a name: integration hell. Diego works for three weeks on the cabin map while a colleague refactors the fare model; each tests on their own laptop and everything works. When it is brought together, conflicts appear, signatures do not match and a bug shows up that nobody can attribute — right on the Friday of the release. The cost of integrating grows non-linearly with how long you take to do it, hence the counterintuitive conclusion: if integrating hurts, do it more often.

The cultural rule that holds it up: if the main build breaks, fixing it is the team's number one priority. A broken build that is tolerated for days turns the pipeline into noise everybody ignores.

An agent is the machine that runs the steps. There are two kinds, and choosing wrong costs money or flat out stops you deploying:

Real cost warning: a private project gets 1 hosted parallel job with 1,800 free minutes a month. Once those are gone, runs queue until the following month or you have to buy additional parallel jobs (around $40/month each). Public projects get 10 free parallel jobs with unlimited minutes, which makes making a repository public tempting: do not do it to save money. With self-hosted agents the first parallel job is free and the following ones cost around $15/month, but you pay for the virtual machine and its maintenance.

Contoso needs both. The build pipeline (this lesson) runs on hosted agents: it touches nothing private and benefits from always-current images. The deployment pipeline (05-04) that acts against sql-contoso-reservas-pro needs to be inside vnet-contoso-pro, because that server has only been reachable through pe-sql-reservas since we locked it down in 02-05: there you need a self-hosted agent in snet-gestion, grouped into the pool-contoso-privado pool.

The agent VM must authenticate against Azure with a managed identity, not with stored credentials: the same principle as module 4.

The decisive argument is the first one: if the pipeline lives in the repository, a change to how you build goes through the same review as a code change, is recorded and can be reverted. With classic, somebody changes a step on a Tuesday afternoon, the build starts behaving differently and there is no history to consult. Contoso uses YAML exclusively.

This is the contoso-reservas-ci pipeline, at the root of the repository:

On the structure: trigger and pr are the two push triggers (trigger: none disables automatic starting, typical in deployment pipelines). The stages → jobs → steps hierarchy means that a stage is a logical phase and can carry approvals, a job runs in its entirety on one agent and several can run in parallel, and a step is an individual action. The difference between task and script is that a task is a reusable component with named inputs and a version (@2), whereas a script is a shell command: use tasks when they bring something real — publishing results, authenticating — and scripts when the command is clear, because they are more readable and portable. And condition: succeededOrFailed() forces a step to run even if the previous one failed.

Restore always explicitly, without relying on what "was already" on the machine. Build with -warnaserror, which turns warnings into errors; without it they pile up in the hundreds and stop being read. Test while publishing results and coverage, with failTaskOnFailedTests: true — and beware of turning coverage into a target: demanding 90% produces tests that walk through code without checking anything. Publish the artifact, which enshrines the principle of build once, deploy many times: the binary validated in development is exactly the same, bit for bit, as the one that reaches production; rebuilding per environment introduces differences that are impossible to trace.

What is still missing is static analysis, which looks for bugs and vulnerabilities before they exist at runtime, and caching, which brings restore time down from minutes to seconds:

Never cache build outputs, only downloaded dependencies.

A secret is never written in the YAML, which is in the repository and in every clone; we already saw in 05-02 what a committed secret costs. The correct way is to link a variable group to kv-contoso-pro:

Three details that save you grief. Secret variables are not exposed automatically as environment variables; the explicit env: mapping is a deliberate protection. Azure Pipelines masks secrets in the logs, but it is not infallible: if your script prints the value transformed (base64-encoded, for instance), the masking will not recognize it. And --authorize false forces you to authorize which pipelines may use the group, which is least privilege applied to build secrets: the pipeline of a test application has no business being able to read the payment gateway key.

Contoso has four repositories that build the same way. Copying the YAML into each one means four places to update when the SDK changes. Templates solve that. In contoso-infra, the file plantillas/compilar-dotnet.yml:

Usage from the contoso-api-disponibilidad repository:

The ref pinned to a tag stops a change to the template from breaking all four pipelines at once: the update happens by bumping the tag, deliberately. And there is a stricter variant, extends, in which the child pipeline cannot add arbitrary steps, only fill in the gaps that were designed for it:

extends is the mechanism a platform team uses to guarantee that no pipeline can skip the security analysis, however much somebody edits their YAML. It is the delivery equivalent of the policies in 04-06: you do not rely on goodwill, you make it structurally impossible.

With the pr trigger defined and the branch policy from 05-02 pointing at this pipeline, the loop closes:

When you need to verify against several configurations, a matrix generates one job per combination:

maxParallel matters for money: with a single parallel job, a nine-combination matrix does not run nine times faster, it runs in single file and consumes nine times the minutes.

When a pipeline fails, the diagnostic order that saves hours: (1) read the log of the step that failed, not the summary — the real error is usually 30 lines above the last red line; (2) turn on diagnostic logs by setting the system.debug variable to true on a re-run, which shows variable resolution and real paths, where the problem usually lives; (3) reproduce locally by running exactly the commands in the YAML, because 80% of "pipeline-only" failures are environment differences — a variable that exists on your laptop, a file ignored by .gitignore that is present on your machine, or the casing of a name that matters on Linux and not on Windows; and (4) check permissions if the failure mentions authorization: the service connection or the variable group is probably not authorized for this pipeline.

And the status badge in the README.md, which gives immediate visibility into whether main is healthy:

• Building in every environment. It breaks the build once, deploy many times principle: the production binary is no longer the one that was tested. Build once, publish the artifact and reuse it.
• Writing secrets in the YAML. They are in the repository and in every clone. A variable group linked to kv-contoso-pro, always.
• 40-minute pipelines. If the verdict takes longer than a coffee, people stop waiting for it and carry on working on unverified code. Split, cache and parallelize until you are under 10 minutes.
• Tolerating a broken build on main, or living with flaky tests. As soon as red is normal, the pipeline stops meaning anything and the team learns to re-run without looking.
• continueOnError: true for convenience. It turns a step into decoration. Use it only while you tune the threshold of a new tool, and with an expiry date.
• Templates pointing at main. One change breaks every pipeline simultaneously. Pin to a tag and version your templates.
• Tip: set timeoutInMinutes on every job. A hung job burns billable minutes up to the 60 or 360 limit.
• Tip: exclude docs/* and README.md from the trigger. It is one minute of work that saves agent minutes every month.

A colleague proposes this pipeline for Contoso Miles:

1. Identify at least five problems.
2. List the specific changes you would make to fix them.
3. Which one is a security incident, and what has to be done beyond fixing the file?

Contoso adds three pipelines: one builds the website, another the API and another runs integration tests against sql-contoso-reservas-dev, which has a private endpoint. All three run about 20 times a day, 12 minutes each.

1. What kind of agent does each pipeline need, and why?
2. Estimate the monthly hosted-minute consumption and say whether it fits in the free tier.
3. Propose two ways of cutting the spend without giving up verification.

The four repositories build .NET almost identically, but contoso-infra has no unit tests (it is Bicep templates) and contoso-modelos publishes a package instead of a web application. Security requires that no pipeline be able to skip the vulnerable dependency analysis.

1. Would you use template or extends? Justify it against the security requirement.
2. Sketch out the template's parameters.
3. How do you stop updating it from breaking all four pipelines at once?

Solution 1:

1. (a) A secret in the YAML: apiKey is in the repository. (b) trigger on all branches, which builds every working branch and burns minutes. (c) The pr trigger is missing, so the build validation policy has nothing to hook into. (d) continueOnError: true on the tests: the pipeline passes even when they fail. (e) Neither results nor coverage are published. (f) No artifact is published at all: there is nothing to deploy afterwards. (g) UseDotNet pinning the SDK version is missing, so it depends on whatever the agent image happens to ship. (h) No timeoutInMinutes and no readable displayName values.
2. trigger limited to main plus pr: [main]; UseDotNet@2 with 8.0.x; an explicit dotnet restore; build with -warnaserror; dotnet test with --logger trx --collect:"XPlat Code Coverage"; PublishTestResults@2 with failTaskOnFailedTests: true and condition: succeededOrFailed(); coverage publishing; dotnet publish to $(Build.ArtifactStagingDirectory) followed by - publish: with an artifact name; the key replaced by a variable group linked to kv-contoso-pro and mapped with env:; and timeoutInMinutes: 20.
3. The secret. Beyond taking it out of the file it has to be rotated: it is in the Git history and in the logs of every previous run. Then store the new value in the vault and check whether it was misused. Just as in 05-02, deleting is not enough.

Solution 2:

1. Website and API, hosted agents: they need no access to anything private and benefit from a clean, maintained machine. The integration tests, a self-hosted agent in pool-contoso-privado inside snet-gestion, because sql-contoso-reservas-dev is only reachable through its private endpoint and a hosted agent has no route to it. The alternative would be managed scale set agents inside the virtual network.
2. The two hosted pipelines add up to 2 × 20 × 12 = 480 minutes a day, roughly 10,500 a month over 22 working days. The free tier is 1,800, so it is far exceeded; and with a single parallel job the runs would also queue up. You would have to buy additional parallel jobs (~$40/month each).
3. (a) Dependency caching and a shallow clone, to halve those 12 minutes. (b) Exclude irrelevant paths from the trigger and do not build on every push to working branches, but on the pull request. (c) Reserve the full matrix and the slow tests for the nightly build, leaving only the essentials in the fast loop. (d) Compare the cost of a self-hosted agent VM with that of the parallel jobs, which at this volume may well favor the VM.

Solution 3:

1. extends. With template the child pipeline includes the template but can add steps, reorder them or simply not call it; with extends it is obliged to build on top of it and can only fill in the gaps designed for it, so the dependency analysis cannot be skipped by editing the YAML. It is the difference between a recommendation and a rule, the same logic as the policies in 04-06.
2. solutionPath (string, required), artifactName (string), sdkVersion (string, default 8.0.x), runTests (boolean, false for contoso-infra), outputType (web or package, to distinguish contoso-modelos) and additionalSteps (stepList) as the only extension point.
3. By pinning the template repository reference to a tag (ref: refs/tags/plantillas-v1.2) and versioning the templates with semantic versioning. Each repository bumps its tag when it suits, so a breaking change is tried out in one before it spreads. The template lives in contoso-infra, with its branch policies and the mandatory review by Contoso-Infraestructura.

Contoso's main branch is no longer merely protected: it is verified. You understand continuous integration as a discipline — integrate often because integrating late hurts non-linearly — with its four requirements and the cultural rule that holds it up: a broken build is priority number one. You know how to choose between hosted agents, clean and maintained by Microsoft, and self-hosted agents, essential when you have to reach resources that only exist behind a private endpoint inside vnet-contoso-pro; and you know the real numbers: 1,800 minutes and one parallel job free per private project, and about $40 a month for each additional parallel job.

You have written the contoso-reservas-ci azure-pipelines.yml understanding every piece: trigger with path exclusions, pr to hook into the build validation policy from 05-02, schedules for the nightly build that catches what breaks without you touching anything, and the stages → jobs → steps hierarchy with the difference between task and script. Inside it you have put the essentials — restore, build with -warnaserror, test while publishing results and coverage with failTaskOnFailedTests, analyze vulnerable dependencies and publish the artifact — you have sped it up with a cache whose key is derived from the manifest, and you have made it reusable with templates, telling template from extends: only extends turns the security analysis into something no team can skip. And you have kept module 4's rule intact: no secrets in the YAML, all of them in a variable group linked to kv-contoso-pro, mapped explicitly and authorized only to the pipelines that need them.

The result of all this is a file: the web-reservas artifact, built once, tested and waiting. But it is still waiting: nobody has taken it to app-contoso-reservas-pro, and the Friday night deployment carries on exactly as before. In the next lesson, Continuous Deployment with Environments and Approvals, that artifact will travel. You will create the desarrollo, preproduccion and produccion environments with their record of which version is in each one, you will add Marta Ríos' manual approval and the windows that prevent deploying on a Friday afternoon, you will compare the deployment strategies, and you will run Contoso's real blue-green deployment with the preproduccion slot swap you already know from module 2, with backward-compatible database migrations and a rollback that genuinely works.