# Implementing a Release Pipeline

> Chapter 9 of the Courseiva AZ-400 curriculum — https://courseiva.com/learn/az-400/implementing-a-release-pipeline

**Official objective:** 4.2 — Implement a release pipeline

## Introduction

Implementing a release pipeline. This is the automated system that takes your finished code and delivers it to your users reliably, safely, and repeatedly. For the AZ-400 exam, you need to understand how to build this pipeline so that your software releases don't crash the system or require someone to manually click buttons at 2 AM.

## The Restaurant Kitchen Opening Analogy

A head chef is the person who makes sure the restaurant can serve meals to customers all night long. Before the doors open, the chef and their team spend hours preparing. They check the inventory of ingredients, chop vegetables, marinate meats, and set up each station so that when an order comes in, the line cooks can assemble a plate in minutes. The chef also runs a final taste test on every sauce and side dish to catch any seasoning mistakes before a single paying customer tastes the food.

This is exactly what a release pipeline does for software. The release pipeline is the automated kitchen preparation and testing that happens before new code is served to users. Just as the chef runs quality checks on ingredients, the pipeline runs automated tests on code. Just as the chef stages the ingredients at each station, the pipeline deploys the code to a staging environment. And just as the chef has a backup plan for a broken stove or a missing ingredient, the pipeline has rollback steps if something goes wrong. The result is that when a customer orders the new feature — the software equivalent of a dish — it comes out hot, correct, and safe every time, without the head chef having to personally run around the kitchen during dinner rush.

## Core explanation

A release pipeline is a set of automated steps that moves your application code from a source control repository (like GitHub or Azure Repos) into production environments where real users can access it. Before release pipelines existed, software releases were manual and risky. A person would copy files to a server, run scripts by hand, and pray nothing broke. If a mistake happened, the whole website or app could go down for hours.

A release pipeline automates these steps. It is part of a bigger process called continuous delivery (CD). Continuous delivery means every change that passes all automated tests is potentially releasable. The release pipeline is the mechanism that actually carries out that release.

The pipeline has several key parts. The first is an artifact. An artifact is the packaged, compiled version of your code — for example, a .zip file or a Docker container image. The pipeline picks up this artifact from a build pipeline (the part that compiles code and runs unit tests).

Next are stages. A stage is a logical boundary in your deployment process. Common stages include 'Dev', 'Test', 'Staging', and 'Production'. Each stage represents a different environment where your app will run. You might deploy to a Dev environment first for internal testing, then to Staging for final validation, and finally to Production for real users.

Each stage contains jobs and tasks. A job is a unit of work that runs on an agent — a virtual machine or container that executes the tasks. Tasks are the individual actions, like copying files to a server, running a database migration script, or sending a notification email.

Crucially, each stage has approvals and gates. Approvals mean a human must click 'Approve' or 'Reject' before the deployment proceeds. Gates are automated checks — for example, checking that the application's error rate is below 1% before allowing the Production deployment.

Release pipelines can also deploy progressively. You might release a new version to 5% of users first, monitor for issues, then increase to 50%, and finally to 100%. This is called a deployment ring strategy.

Why does this matter? Without a release pipeline, every release is a stressful, error-prone manual process. With one, releases become predictable, auditable, and fast. You can release updates multiple times per day instead of once per month.

The AZ-400 exam expects you to understand three types of deployment strategies commonly implemented in release pipelines:

- Blue-green deployment: You maintain two identical environments. At any time, one is live (blue) and serving all users. You deploy the new version to the idle environment (green). Once it passes tests, you swap the router so users see the green environment. This minimises downtime.
- Canary deployment: You roll out the change to a small subset of servers or users first. You monitor this small group for problems. If everything looks good, you gradually expand the rollout to all users.
- Rolling deployment: You update your servers one at a time (or in small batches) while the rest remain live. Users are gradually shifted to the new version.

You also need to understand release triggers. A release pipeline can start automatically when a new artifact becomes available (continuous deployment trigger), or manually when someone clicks 'Create Release'. You can also schedule releases to happen at specific times.

The tools involved in Azure DevOps include 'Releases' (the classic pipeline designer) and 'Multi-stage pipelines' (the YAML-based pipeline definition). The exam tests both, but the modern approach is multi-stage pipelines defined in a YAML file stored alongside your code.

Finally, the pipeline must handle failures gracefully. If a deployment to Production fails partway through, the pipeline should automatically roll back to the previous version. This is done through deployment slots (in Azure App Service) or by redeploying the old artifact.

In summary, implementing a release pipeline means designing a repeatable, automated, and safe process for delivering software updates. The AZ-400 exam tests your ability to configure stages, approvals, gates, triggers, and deployment strategies.

## Real-world context

An IT professional — say, a DevOps engineer at a company that runs an e-commerce website — uses release pipelines every day. Imagine the company is preparing to launch a new 'one-click checkout' feature. The developer team has written the code and committed it to the main branch in Azure Repos. A build pipeline runs automatically, compiles the code, runs unit tests, and produces a Docker container image as an artifact.

The DevOps engineer now needs to get that container image into production safely. They have already set up a multi-stage release pipeline in Azure DevOps with four stages: Dev, QA, Staging, and Production. Each stage corresponds to an Azure Kubernetes Service (AKS) cluster running in a separate environment.

The first thing the engineer does is check that the release pipeline is configured to trigger automatically when a new build artifact is produced. So, as soon as the build finishes, the release pipeline starts. It deploys the new container to the Dev AKS cluster. The developer team instantly sees the new feature, runs integration tests, and verifies it works.

Next, a manual approval is set for the QA stage. The QA lead receives an email notification. They log into Azure DevOps, inspect the deployment in Dev, and approve the release. The pipeline then deploys to the QA environment, where testers run thousands of automated browser tests to catch visual bugs or broken functionality.

After QA passes, the pipeline moves to the Staging stage. This stage mirrors Production exactly. The engineer has added a deployment gate that checks the application's error rate from Application Insights. If the error rate spikes above 0.5%, the gate blocks the deployment. In this case, a small memory leak is detected, so the gate fails. The pipeline pauses. The engineer investigates, finds the issue in a new dependency library, and the developers fix it. A new build is triggered.

With the fix in place, the pipeline reaches the Production stage. The engineer has configured a canary deployment for Production. The pipeline first deploys the new container to one server node out of ten. Only 10% of users see the new checkout flow. The engineer monitors real user metrics for 30 minutes. Everything looks stable. The pipeline automatically increases the canary to 50%, and then, after another health check, to 100%.

If at any point something had gone wrong — say the error rate jumped — the pipeline would have triggered an automatic rollback, redeploying the previous known-good version.

In this scenario, the DevOps engineer never once logged into a server directly. They didn't copy files manually. They didn't run commands by hand. They designed the pipeline, configured the approvals and gates, and then let automation handle the rest. That is the real-world power of a release pipeline.

## Exam focus

The AZ-400 exam tests your understanding of release pipelines heavily. Expect around 15-20% of your exam questions to come from this area. The official exam objective 'Implement a release pipeline' covers several subtopics. The exam loves to test the following:

Key concepts you must memorise:

- The difference between a build pipeline and a release pipeline. The build pipeline produces an artifact; the release pipeline deploys it.
- The three deployment strategies: blue-green, canary, and rolling. Know the pros and cons of each, especially blue-green (requires double infrastructure) and canary (uses real user traffic for testing).
- Approval types: pre-deployment approvals (before a stage starts) and post-deployment approvals (after a stage completes, before the next one begins). The exam may ask who can approve and how to configure multiple approvers.
- Gates: Azure Monitor alerts, Azure Functions returning a status, or querying a work item tracker. Gates are evaluated before a deployment continues.
- Triggers: continuous deployment trigger (automatic based on build completion), scheduled trigger (nightly releases), and manual trigger.

Common traps in the exam:

- Confusing 'release' with 'deployment'. A release is a package of artifacts and configuration; a deployment is the act of applying that release to an environment. One release can be deployed to many environments.
- Thinking that a release pipeline requires a separate agent. It does not; it runs on the same agent pool as build pipelines.
- Forgetting that deployment slots are only available for Azure App Service and Azure Functions, not for virtual machines. The exam may ask you to choose the correct tool for a scenario.
- Overlooking rollback strategies. Know how to use deployment slots to swap back, or how to redeploy an older artifact.

Question types you will see:

- Multiple choice: 'Which deployment strategy minimises downtime by running two identical environments?' Answer: blue-green.
- Scenario-based: 'Your company must release to 10% of users first. Which strategy?' Answer: canary.
- Drag and drop: Order the stages of a release pipeline correctly (e.g., Dev -> Test -> Staging -> Production).
- Yes/No: 'Can you use a deployment gate with a manual approval?' Answer: Yes, they can be combined.

The exam also expects you to understand how to configure these in Azure DevOps UI and in YAML. For example, they might show you a YAML snippet and ask you what it does. Practise reading YAML structures with stages, jobs, tasks, and approvals.

Finally, the exam tests 'release pipeline variables' and 'variable groups'. Variables allow you to reuse values (like a database connection string) across stages. Variable groups store secrets linked to a key vault. Know how to link a variable group to a pipeline and how to override variables at release time.

## Step by step

1. **Create a Release Pipeline** — In Azure DevOps, you first create a release pipeline using either the classic editor or a YAML file. You define the artifact source (e.g., a build pipeline in the same project) and the name of the pipeline. This sets the foundation for all subsequent steps.
2. **Define Stages and Environments** — You add stages like Dev, Test, Staging, and Production. Each stage represents a target environment where the application will run. You configure the deployment method for each stage (e.g., deploy to Azure App Service, deploy to a Kubernetes cluster).
3. **Configure Pre-deployment Approvals** — For sensitive stages (like Production), you add pre-deployment approvals. You specify who must approve (individual users or a group) and whether multiple approvals are required. The pipeline pauses and sends a notification until all approvals are granted.
4. **Add Deployment Gates** — You add gates that run automated checks before the deployment proceeds. For example, you can set a gate that queries Azure Monitor to ensure the error rate is below a threshold. If the gate fails, the deployment is blocked or automatically rolls back.
5. **Define Deployment Jobs and Tasks** — Within each stage, you configure jobs that run specific tasks. A job might run on an agent and execute tasks like: deploy ARM template, run database migrations, copy files, or run smoke tests. Multiple jobs can run in parallel or sequentially.
6. **Set Up Release Triggers** — You configure when the pipeline should start. A continuous deployment trigger starts a release automatically every time a new build artifact is produced. A scheduled trigger runs at specific times, e.g., every night at 2 AM. A manual trigger requires someone to click 'Create Release'.
7. **Test and Observe the Deployment** — You create a release and watch it flow through the stages. You monitor logs for each stage, check for failures, and verify that gates and approvals work. If a stage fails, the pipeline stops, and you investigate the error. You can also rerun a failed stage from the portal.

## Comparisons

### Blue-green deployment vs Canary deployment

**Blue-green deployment:**
- Two full, separate environments are maintained.
- Traffic is switched instantly from blue to green.
- Requires double infrastructure cost.

**Canary deployment:**
- One environment, but traffic is gradually shifted.
- Only a small percentage of users see the new version initially.
- Does not require double infrastructure; uses existing servers.

### Pre-deployment approval vs Deployment gate

**Pre-deployment approval:**
- Requires a human to manually approve or reject.
- Can be configured for multiple approvers (e.g., two of three).
- Evaluated once before the stage starts.

**Deployment gate:**
- Automated check (e.g., monitoring query or function).
- Evaluated repeatedly over a period (default 4 hours).
- Can be combined with manual approvals for layered safety.

### Classic release pipeline (UI) vs YAML multi-stage pipeline

**Classic release pipeline (UI):**
- Created and managed through the Azure DevOps web portal.
- Not stored in source control; changes are not versioned.
- Easier to learn for beginners with a drag-and-drop interface.

**YAML multi-stage pipeline:**
- Defined in a YAML file stored in your repository.
- Version-controlled like any code; can be reviewed in pull requests.
- More portable and repeatable across projects.

### Continuous delivery (CD) vs Continuous deployment (also CD)

**Continuous delivery (CD):**
- Every change that passes tests is potentially releasable.
- A human still approves the final deployment to production.
- The release pipeline deploys to all non-production environments automatically.

**Continuous deployment (also CD):**
- Every change that passes tests goes to production automatically.
- No human approval step for production.
- Requires high confidence in automated testing and monitoring.

## Diagram

_How a release pipeline takes code from build to production with stages, gates, and a canary rollout._

```mermaid
flowchart TD
    A[Source Code in Repo] --> B[Build Pipeline]
    B --> C[Artifact: Docker Image]
    C --> D[Release Pipeline Trigger]
    D --> E[Stage 1: Dev Environment]
    E --> F{Approval Gate?}
    F -- Manual Approval --> G[Stage 2: Test Environment]
    G --> H{Automated Gate: Error Rate < 1%?}
    H -- Pass --> I[Stage 3: Staging]
    I --> J{Deploy Strategy?}
    J -- Canary 10% --> K[Stage 4: Production Canary]
    K --> L[Monitor Metrics]
    L -- Healthy --> M[Rollout to 100%]
    L -- Unhealthy --> N[Rollback to Previous Version]
```

## Common misconceptions

- **Misconception:** A release pipeline is the same thing as a build pipeline. **Reality:** A build pipeline compiles code and runs unit tests to produce an artifact. A release pipeline takes that artifact and deploys it to environments. They are two separate pipelines that work together. (The words 'build' and 'release' are used interchangeably in casual conversation, and many beginners see them as one step. The exam explicitly tests the difference.)
- **Misconception:** Once a release pipeline is set up, no human involvement is needed. **Reality:** Release pipelines can include manual approval gates for safety. Many organisations require a human to approve deployments to production. The pipeline automates the busy work, not the accountability. (Beginners hear 'automation' and assume it means fully autonomous. In real life, critical deployments often need a person to watch and approve.)
- **Misconception:** A canary deployment replaces the whole environment at once, like blue-green. **Reality:** A canary deployment gradually shifts traffic from old to new versions on the same infrastructure. A blue-green deployment swaps between two fully separate environments. (Both strategies sound similar — they both reduce risk — but the mechanism is completely different. The exam loves to confuse them.)
- **Misconception:** You can use deployment slots for any Azure resource, including virtual machines. **Reality:** Deployment slots are a feature of Azure App Service (web apps, API apps) and Azure Functions. You cannot use slots with virtual machines or Azure Kubernetes Service. Those require different strategies like rolling or blue-green. (The word 'slot' sounds generic, so beginners assume it works everywhere. The exam uses this to trap candidates who pick the wrong tool for the scenario.)
- **Misconception:** Release pipeline gates are optional and not very important for the exam. **Reality:** Gates are a core concept. The exam asks about them frequently — how to configure them, what metrics they check, and when they are evaluated. They are a key difference between a basic pipeline and a safe pipeline. (Gates are easy to overlook because they are not as visual as approvals or triggers. But they are a major topic in the official AZ-400 study materials.)

## Key takeaways

- A release pipeline automates the deployment of an artifact across multiple environments, ensuring repeatability and safety.
- The three main deployment strategies are blue-green, canary, and rolling, each with distinct infrastructure and traffic patterns.
- Approvals and gates provide manual and automated safety checks before a deployment proceeds to a production environment.
- A release is a reusable package; a deployment is the act of applying that release to a specific environment.
- Deployment slots are an Azure App Service feature that enables zero-downtime swaps, not available for virtual machines.
- You can combine manual approvals with automated gates in the same stage for layered validation.
- Release triggers can be continuous, scheduled, or manual, and you can set different triggers per stage.

## FAQ

**What is the difference between a build pipeline and a release pipeline in Azure DevOps?**

A build pipeline (CI) compiles your code, runs unit tests, and produces an artifact like a .zip file or Docker image. A release pipeline (CD) takes that artifact and deploys it to development, testing, staging, and production environments.

**Can I use the same release pipeline for multiple applications?**

Yes, but you must configure each application as a separate artifact source within the same pipeline, or use variables to switch between apps. It is more common to have one pipeline per application for clarity.

**What is a deployment gate and how is it different from an approval?**

A deployment gate is an automated check (like a monitoring alert or a function return value) that must pass before the deployment proceeds. An approval is a manual sign-off by a human. Both can be used together.

**How do I roll back a bad deployment in a release pipeline?**

You configure an automatic rollback task in the pipeline, or use deployment slots to swap back to the previous version. In a blue-green deployment, you simply swap the traffic back to the old environment.

**What is a YAML release pipeline vs a classic release pipeline?**

YAML pipelines are defined in a YAML file stored in your repository, making them version-controlled and repeatable. Classic pipelines are created through the Azure DevOps web UI. The exam tests both, but YAML is the modern standard.

**Can a release pipeline deploy to multiple environments at the same time?**

Yes, if you define parallel stages in your pipeline. For example, you could deploy the same artifact to Dev and Test simultaneously. But for safety, most companies deploy to environments sequentially, especially Production.

**What is a deployment slot in Azure App Service?**

A deployment slot is a separate instance of your web app that has its own hostname. You can deploy a new version to a staging slot, then swap it with the production slot with zero downtime.

## Check your understanding

1. **Which deployment strategy uses two identical environments and switches traffic between them?**

   Answer: Blue-green deployment.

2. **What is the main difference between a deployment gate and a manual approval?**

   Answer: A deployment gate is an automated check (e.g., error rate below threshold), while a manual approval requires a human to click approve.

3. **Can you use deployment slots for a virtual machine running in Azure?**

   Answer: No, deployment slots are only available for Azure App Service and Azure Functions.

4. **What does a release pipeline deploy?**

   Answer: A release pipeline deploys an artifact — the packaged, tested output of a build pipeline.

5. **In a canary deployment, what happens if the error rate increases after the initial 10% rollout?**

   Answer: The pipeline should automatically roll back to the previous version or block further rollout.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/az-400/implementing-a-release-pipeline