Release pipeline basics in Azure - Step-by-Step Execution

Process Flow - Release pipeline basics

Start Release Pipeline

↓

Fetch Artifacts

↓

Deploy to Environment

↓

Run Tests

↓

Approve Deployment?

No→Stop Pipeline

Yes↓

Deploy to Next Environment or Finish

↓

End

The release pipeline starts by fetching build artifacts, then deploys them to an environment, runs tests, waits for approval, and either stops or continues to the next environment until finished.

Execution Sample

Azure

Start pipeline
Fetch artifacts
Deploy to Dev
Run tests
Approve deployment
Deploy to Prod

This sequence shows a release pipeline deploying code first to a development environment, running tests, then after approval, deploying to production.

Process Table

Step	Action	Result	Next Step
1	Start pipeline	Pipeline started	Fetch artifacts
2	Fetch artifacts	Artifacts ready	Deploy to Dev
3	Deploy to Dev	Code deployed to Dev	Run tests
4	Run tests	Tests passed	Approve deployment
5	Approve deployment	Approval granted	Deploy to Prod
6	Deploy to Prod	Code deployed to Prod	End pipeline
7	End pipeline	Pipeline finished successfully	None

💡 Pipeline ends after successful deployment to production.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	Final
Pipeline Status	Not started	Artifacts fetched	Deployed to Dev	Tests passed	Approved	Deployed to Prod	Finished
Environment	None	None	Dev	Dev	Dev	Prod	Prod
Approval	Pending	Pending	Pending	Pending	Granted	Granted	Granted

Key Moments - 2 Insights

Why does the pipeline stop if approval is not granted?

Because the approval step controls whether deployment continues. As shown in step 5 of the execution_table, if approval is not granted, the pipeline stops to prevent unwanted deployments.

What happens if tests fail after deployment to Dev?

The pipeline would stop after the 'Run tests' step (step 4) because tests must pass to proceed. This prevents deploying faulty code to production.

Visual Quiz - 3 Questions

Look at the execution_table, what is the pipeline status after step 3?

A Deployed to Dev

B Artifacts fetched

C Tests passed

D Approved

💡 Hint

Check the 'Pipeline Status' row in variable_tracker after step 3.

At which step does the pipeline wait for approval?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look at the 'Action' column in execution_table for the approval step.

If tests fail at step 4, what happens next?

A Pipeline continues to deploy to Prod

B Pipeline stops

C Pipeline retries tests automatically

D Pipeline skips approval

💡 Hint

Refer to key_moments about test failure consequences.

Concept Snapshot

Release pipeline basics:
- Starts by fetching build artifacts
- Deploys to an environment (e.g., Dev)
- Runs tests to verify deployment
- Waits for manual approval before next deployment
- Deploys to next environment or finishes
- Stops if tests fail or approval denied

Full Transcript

A release pipeline automates deploying code through stages. It begins by fetching the build artifacts. Then it deploys the code to a development environment. After deployment, it runs tests to ensure the code works. If tests pass, the pipeline waits for a manual approval. Once approved, it deploys to the production environment. The pipeline stops if tests fail or approval is not granted. This process ensures safe and controlled code releases.

Practice

1. What is the main purpose of a release pipeline in Azure DevOps?

easy

A. To monitor user activity on a website

B. To automate the delivery of applications through different stages

C. To write code for applications

D. To store application data securely

Solution

1. Step 1: Understand the role of a release pipeline

   A release pipeline automates the process of delivering software through stages like testing and production.

2. Step 2: Identify the correct purpose

   Among the options, only automating delivery matches the release pipeline's function.

3. Final Answer:

   To automate the delivery of applications through different stages -> Option B

4. Quick Check:

   Release pipeline = automate delivery [OK]

Hint: Release pipelines automate app delivery stages [OK]

Common Mistakes:

• Confusing release pipeline with coding or monitoring tools
• Thinking it stores data instead of deploying apps

2. Which syntax correctly defines a stage in an Azure release pipeline YAML?

easy

A. stage:
- Build
jobs: []

B. jobs:
- stage: Build

C. stages:
Build:
jobs: []

D. stages:
- stage: Build
jobs: []

Solution

1. Step 1: Review YAML structure for stages

   In Azure pipelines, stages are defined under 'stages:' as a list with '- stage:' entries.

2. Step 2: Match correct syntax

   stages: - stage: Build jobs: [] correctly uses 'stages:' followed by '- stage: Build' and an empty jobs list.

3. Final Answer:

   stages: - stage: Build jobs: [] -> Option D

4. Quick Check:

   Stages list starts with 'stages:' and '- stage:' [OK]

Hint: Stages use 'stages:' then '- stage:' list items [OK]

Common Mistakes:

• Using singular 'stage:' instead of 'stages:'
• Placing 'stage' inside 'jobs' incorrectly
• Incorrect indentation or list syntax

3. Given this YAML snippet in a release pipeline:

stages:
  - stage: Test
    jobs:
      - job: RunTests
        steps:
          - script: echo Testing

What will be the output when this pipeline runs?

medium

A. It will print 'Testing' in the job logs

B. It will print 'echo Testing' literally

C. No output will be shown

D. The pipeline will fail due to syntax error

Solution

1. Step 1: Understand the script step in pipeline

   The 'script' step runs the command given, here 'echo Testing', which prints 'Testing'.

2. Step 2: Predict output

   Since the script runs successfully, the output 'Testing' appears in the job logs.

3. Final Answer:

   It will print 'Testing' in the job logs -> Option A

4. Quick Check:

   Script runs command, prints output [OK]

Hint: Script steps run commands and show output [OK]

Common Mistakes:

• Thinking script prints the command text instead of output
• Assuming syntax error without checking YAML correctness
• Expecting no output from script step

4. You have this YAML snippet in a release pipeline:

stages:
  - stage: Deploy
    jobs:
      - job: DeployJob
        steps:
          - script: echo Deploying
          - script: echo Done
        dependsOn: Build

What is wrong with this pipeline configuration?

medium

A. 'dependsOn' should be inside the stage, not inside jobs

B. 'dependsOn' must be a job, not a stage

C. The 'steps' section cannot have multiple scripts

D. The 'jobs' keyword is not allowed inside stages

Solution

1. Step 1: Locate 'dependsOn' usage

   'dependsOn' controls stage dependencies and must be placed at the stage level, not inside jobs.

2. Step 2: Identify correct placement

   In the snippet, 'dependsOn: Build' is incorrectly placed inside the job, it should be directly under the stage.

3. Final Answer:

   'dependsOn' should be inside the stage, not inside jobs -> Option A

4. Quick Check:

   'dependsOn' belongs to stage level [OK]

Hint: 'dependsOn' goes under stage, not job [OK]

Common Mistakes:

• Placing 'dependsOn' inside jobs instead of stages
• Thinking 'dependsOn' applies to jobs only
• Believing multiple scripts in steps is invalid

5. You want to create a release pipeline with two stages: Build and Deploy. Deploy should only run if Build succeeds. Which YAML snippet correctly sets this up?

hard

A. stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building
- stage: Deploy
jobs:
- job: DeployJob
steps:
- script: echo Deploying

B. stages:
- stage: Build
dependsOn: Deploy
jobs:
- job: BuildJob
steps:
- script: echo Building
- stage: Deploy
jobs:
- job: DeployJob
steps:
- script: echo Deploying

C. stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building
- stage: Deploy
dependsOn: Build
jobs:
- job: DeployJob
steps:
- script: echo Deploying

D. stages:
- stage: Deploy
dependsOn: Build
jobs:
- job: DeployJob
steps:
- script: echo Deploying
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building

Solution

1. Step 1: Understand stage dependencies

   To run Deploy only after Build succeeds, Deploy stage must depend on Build.

2. Step 2: Check YAML for correct 'dependsOn'

   stages: - stage: Build jobs: - job: BuildJob steps: - script: echo Building - stage: Deploy dependsOn: Build jobs: - job: DeployJob steps: - script: echo Deploying places 'dependsOn: Build' under Deploy stage, correctly setting the dependency.

3. Step 3: Verify order and jobs

   Build stage is first, Deploy second, with proper jobs and steps defined.

4. Final Answer:

   Correctly sets Deploy to depend on Build -> Option C

5. Quick Check:

   'dependsOn' on Deploy stage = correct dependency [OK]

Hint: Use 'dependsOn' on Deploy stage to wait for Build [OK]

Common Mistakes:

• Reversing 'dependsOn' causing wrong execution order
• Omitting 'dependsOn' so stages run in parallel
• Placing stages in wrong order without dependencies