Build pipeline basics in Azure - Deep Dive

Overview - Build pipeline basics

What is it?

A build pipeline is a set of automated steps that take your code and turn it into a ready-to-use application or package. It checks your code, compiles it, runs tests, and prepares it for deployment. This process happens every time you make changes, ensuring your software is always up to date and working correctly.

Why it matters

Without build pipelines, developers would have to manually check and prepare their code, which is slow and error-prone. This could lead to bugs, delays, and unhappy users. Build pipelines make software delivery faster, safer, and more reliable, helping teams deliver better products more often.

Where it fits

Before learning build pipelines, you should understand basic coding and version control (like Git). After mastering build pipelines, you can learn about release pipelines and deployment automation to deliver software to users.

Mental Model

Core Idea

A build pipeline is an automatic assembly line that transforms raw code into a tested, ready-to-use product.

Think of it like...

Imagine a car factory where raw parts come in, get assembled, checked for quality, and come out as a finished car ready to drive. The build pipeline is like that factory for software.

Code Source ──▶ Build Server ──▶ Compile ──▶ Test ──▶ Package ──▶ Ready Application

Build-Up - 7 Steps

1

Foundation

What is a Build Pipeline

Concept: Introduces the basic idea of a build pipeline as an automated process for preparing software.

A build pipeline is a series of steps that automatically take your code from the place you write it (like GitHub) and turn it into something usable. These steps include checking the code, compiling it into a program, running tests to catch errors, and packaging it for deployment.

Result

You get a consistent, error-checked version of your software ready to use or deploy.

Understanding that build pipelines automate repetitive tasks helps you see how they save time and reduce mistakes.

2

Foundation

Key Components of a Build Pipeline

Concept: Explains the main parts of a build pipeline: source, build, test, and package.

Every build pipeline has these parts: - Source: Where your code lives. - Build: Turning code into a program. - Test: Running checks to find problems. - Package: Preparing the program for delivery. Each part must work well for the pipeline to succeed.

Result

You can identify what each step in a pipeline does and why it matters.

Knowing the pipeline parts helps you understand how software moves from code to product.

3

Intermediate

Setting Up a Simple Azure Build Pipeline

🤔Before reading on: do you think setting up a build pipeline requires writing complex code or just configuring steps? Commit to your answer.

Concept: Shows how to create a basic build pipeline in Azure DevOps using simple configuration.

In Azure DevOps, you create a build pipeline by linking your code repository and defining steps in a YAML file or using a visual editor. Steps include installing dependencies, compiling code, running tests, and publishing artifacts. Azure provides templates to help you start quickly.

Result

You have a working build pipeline that runs automatically when you update your code.

Understanding that build pipelines can be set up with simple configurations lowers the barrier to automation.

4

Intermediate

Common Build Pipeline Triggers

🤔Before reading on: do you think build pipelines run only when you ask them to, or can they start automatically? Commit to your answer.

Concept: Introduces triggers that start the build pipeline automatically based on events.

Build pipelines can start automatically when you push code changes, create a pull request, or on a schedule. This ensures your software is always tested and built without manual effort. In Azure, you define triggers in the pipeline configuration.

Result

Your build pipeline runs automatically at the right times, keeping your software fresh.

Knowing about triggers helps you automate builds and catch problems early.

5

Intermediate

Understanding Build Artifacts

🤔Before reading on: do you think build artifacts are temporary files or important outputs? Commit to your answer.

Concept: Explains what build artifacts are and why they matter.

Build artifacts are the files produced by the build pipeline, like compiled programs or packages. They are saved so later steps or teams can use them for deployment or testing. In Azure, artifacts are stored securely and can be shared across pipelines.

Result

You can identify and manage the outputs of your build pipeline effectively.

Recognizing artifacts as valuable outputs helps you connect build and deployment processes.

6

Advanced

Optimizing Build Pipelines for Speed

🤔Before reading on: do you think running all tests every time is always best, or can some be skipped? Commit to your answer.

Concept: Teaches techniques to make build pipelines faster and more efficient.

You can speed up build pipelines by caching dependencies, running tests in parallel, and only building changed parts of the code. Azure DevOps supports caching and parallel jobs to reduce wait times. This helps teams get feedback faster.

Result

Your build pipeline runs quicker, improving developer productivity.

Knowing how to optimize builds prevents slowdowns that frustrate teams and delay releases.

7

Expert

Handling Complex Build Pipeline Dependencies

🤔Before reading on: do you think build pipelines always run steps in a simple order, or can they handle complex branching and conditions? Commit to your answer.

Concept: Explores advanced pipeline features like conditional steps, multiple jobs, and dependencies.

Advanced build pipelines can run different steps based on conditions, run jobs in parallel or sequence, and share artifacts between jobs. Azure DevOps YAML supports these features, allowing complex workflows like building multiple components or running different tests per platform.

Result

You can design flexible, powerful build pipelines that fit complex projects.

Understanding pipeline dependencies and conditions unlocks the ability to automate sophisticated software workflows.

Under the Hood

Build pipelines work by running a series of automated tasks on build agents—special computers that execute commands. When triggered, the pipeline fetches the latest code, runs scripts to compile and test it, and stores the results as artifacts. Azure DevOps manages these agents and coordinates the steps, ensuring each runs in order or in parallel as configured.

Why designed this way?

Build pipelines were designed to automate repetitive, error-prone manual steps in software delivery. Early software projects suffered from inconsistent builds and slow feedback. Automating builds with pipelines ensures consistency, speed, and reliability. Azure DevOps chose a flexible YAML-based configuration to allow both simple and complex pipelines, supporting many project types and team sizes.

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│ Code Repo  │────▶│ Build Agent │────▶│ Test Agent  │
└─────────────┘     └─────────────┘     └─────────────┘
       │                  │                  │
       ▼                  ▼                  ▼
  Trigger Event      Compile Code       Run Tests
       │                  │                  │
       ▼                  ▼                  ▼
  ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
  │ Artifacts  │◀────│ Package     │◀────│ Test Result │
  └─────────────┘     └─────────────┘     └─────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do build pipelines only run when a developer manually starts them? Commit to yes or no.

Common Belief: Build pipelines only run when someone clicks a button to start them.

Reality: Build pipelines can be set to run automatically on code changes, pull requests, or schedules without manual intervention.

Why it matters: Believing pipelines run only manually leads to missed automation benefits and slower feedback cycles.

Quick: Are build artifacts just temporary files that can be ignored? Commit to yes or no.

Common Belief: Build artifacts are temporary and not important after the build finishes.

Reality: Build artifacts are crucial outputs used for deployment, testing, and sharing between pipeline stages.

Why it matters: Ignoring artifacts can cause deployment failures or repeated work, wasting time and resources.

Quick: Do you think build pipelines always run all tests every time? Commit to yes or no.

Common Belief: Every build must run all tests to be safe.

Reality: Selective testing and caching can speed up builds without sacrificing quality by running only relevant tests.

Why it matters: Not optimizing tests can cause slow builds, frustrating developers and delaying releases.

Quick: Can build pipelines only handle simple linear steps? Commit to yes or no.

Common Belief: Build pipelines are simple and cannot handle complex workflows.

Reality: Modern pipelines support conditional steps, parallel jobs, and dependencies to handle complex projects.

Why it matters: Underestimating pipeline capabilities limits automation and project scalability.

Expert Zone

1

Build pipelines can integrate with multiple repositories and services, requiring careful management of credentials and permissions.

2

Caching strategies must balance speed and correctness; stale caches can cause hard-to-debug errors.

3

Pipeline YAML files can be templated and reused across projects, promoting consistency but requiring disciplined version control.

When NOT to use

Build pipelines are not suitable for one-off scripts or very small projects where manual builds are faster. For deployment-only tasks, release pipelines or simpler automation tools may be better.

Production Patterns

In production, build pipelines are often part of a larger CI/CD system, triggering release pipelines after successful builds. Teams use branching strategies like GitFlow to control when builds run and deploy. Pipelines include quality gates like code coverage and security scans before allowing deployment.

Connections

Continuous Integration

Build pipelines are the core automation step in continuous integration workflows.

Understanding build pipelines clarifies how continuous integration keeps code healthy and ready for release.

Manufacturing Assembly Lines

Build pipelines share the pattern of sequential automated steps assembling a product.

Seeing build pipelines as assembly lines helps grasp the importance of order, quality checks, and automation in software delivery.

Project Management Workflows

Build pipelines automate repetitive tasks similar to how workflows automate project steps.

Recognizing automation patterns across domains shows how pipelines reduce human error and speed up processes.

Common Pitfalls

#1 Triggering builds manually and forgetting to automate.

Wrong approach:

pipeline:
trigger: none
steps:
- script: echo Build started manually

Correct approach:

pipeline:
trigger:
branches:
include:
- main
steps:
- script: echo Build triggered automatically on code change

Root cause:

Not setting triggers leads to builds only running when started manually, losing automation benefits.

#2 Not saving build artifacts for later use.

Wrong approach:

steps:
- script: dotnet build
- script: dotnet test

Correct approach:

steps:
- script: dotnet build
- script: dotnet test
- publish: $(Build.ArtifactStagingDirectory)
artifact: drop

Root cause:

Forgetting to publish artifacts means outputs are lost and cannot be deployed or tested further.

#3 Running all tests every time without optimization.

Wrong approach:

steps:
- script: run_all_tests.sh

Correct approach:

steps:
- script: run_changed_tests.sh
- cache: dependencies

Root cause:

Not optimizing tests causes slow builds and wastes resources.

Key Takeaways

Build pipelines automate the process of turning code into tested, ready-to-use software.

They consist of key steps: fetching code, building, testing, and packaging artifacts.

Triggers allow pipelines to run automatically on code changes, speeding feedback.

Artifacts are important outputs used for deployment and further testing.

Advanced pipelines support complex workflows with conditions, parallel jobs, and dependencies.

Practice

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

easy

A. To manually test code changes

B. To store code in a repository

C. To automate the process of preparing code for deployment

D. To monitor user activity on a website

Solution

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

   A build pipeline automates tasks like compiling code and running tests when code changes.

2. Step 2: Identify the main goal

   The main goal is to prepare code automatically for deployment or further steps.

3. Final Answer:

   To automate the process of preparing code for deployment -> Option C

4. Quick Check:

   Build pipeline purpose = automate code preparation [OK]

Hint: Build pipelines automate code prep, not manual tasks [OK]

Common Mistakes:

• Confusing build pipeline with code repository
• Thinking build pipelines monitor user activity
• Assuming build pipelines are for manual testing

2. Which YAML snippet correctly defines a trigger for a build pipeline on the 'main' branch?

easy

A. trigger:\n branches:\n - main

B. trigger:\n branches:\n exclude:\n - main

C. trigger:\n paths:\n include:\n - main

D. trigger:\n branches:\n include:\n - main

Solution

1. Step 1: Understand trigger syntax in YAML

   The trigger block uses 'branches' with 'include' to specify branches that start the pipeline.

2. Step 2: Check each option

   trigger:\n branches:\n include:\n - main correctly includes 'main' branch under 'branches' and 'include'. trigger:\n branches:\n exclude:\n - main excludes 'main', which disables trigger on it. trigger:\n paths:\n include:\n - main uses 'paths' which triggers on file changes, not branches. trigger:\n branches:\n - main misses 'include' keyword, so syntax is incorrect.

3. Final Answer:

   trigger:\n branches:\n include:\n - main -> Option D

4. Quick Check:

   Correct trigger syntax includes branches: include [OK]

Hint: Use 'branches: include:' to trigger on specific branches [OK]

Common Mistakes:

• Using 'exclude' instead of 'include' to trigger
• Confusing 'paths' with 'branches' in triggers
• Omitting 'include' keyword causing syntax errors

3. Given this YAML snippet in an Azure build pipeline, what will be the output of the script step?

steps:
- script: echo Hello, Azure DevOps!
  displayName: 'Print greeting'

medium

A. No output, script step is missing

B. Hello, Azure DevOps!

C. script: echo Hello, Azure DevOps!

D. Print greeting

Solution

1. Step 1: Understand the script step in YAML

   The 'script' keyword runs the command given, here 'echo Hello, Azure DevOps!'.

2. Step 2: Identify the output of the echo command

   The echo command prints the text 'Hello, Azure DevOps!' to the pipeline logs.

3. Final Answer:

   Hello, Azure DevOps! -> Option B

4. Quick Check:

   Script echo output = Hello, Azure DevOps! [OK]

Hint: Script runs commands; echo prints text to output [OK]

Common Mistakes:

• Confusing displayName with output
• Thinking script keyword prints itself
• Assuming no output if displayName is set

4. You wrote this YAML snippet for a build pipeline but it fails to trigger on the 'develop' branch:

trigger:
  branches:
    include:
      - main
steps:
- script: echo Build started

What is the likely cause?

medium

A. The trigger only includes the 'main' branch, not 'develop'

B. The script step is missing a displayName

C. The echo command is incorrect syntax

D. The YAML indentation is invalid

Solution

1. Step 1: Analyze the trigger branches

   The trigger includes only the 'main' branch, so changes in 'develop' won't start the pipeline.

2. Step 2: Check other parts for errors

   The script step is valid without displayName, echo syntax is correct, and indentation looks fine.

3. Final Answer:

   The trigger only includes the 'main' branch, not 'develop' -> Option A

4. Quick Check:

   Trigger branches must include target branch [OK]

Hint: Check trigger branches include all needed branches [OK]

Common Mistakes:

• Assuming script needs displayName to run
• Thinking echo command syntax causes trigger failure
• Ignoring trigger branch filters

5. You want to create a build pipeline that triggers only when files in the 'src/' folder change on the 'release' branch. Which YAML snippet correctly sets this up?

hard

A. trigger:\n branches:\n include:\n - release\n paths:\n include:\n - src/**

B. trigger:\n branches:\n include:\n - release\n paths:\n exclude:\n - src/**

C. trigger:\n branches:\n exclude:\n - release\n paths:\n include:\n - src/**

D. trigger:\n branches:\n include:\n - main\n paths:\n include:\n - src/**

Solution

1. Step 1: Understand branch and path filters

   To trigger on 'release' branch and only when files in 'src/' change, include 'release' in branches and 'src/**' in paths.

2. Step 2: Evaluate each option

   trigger:\n branches:\n include:\n - release\n paths:\n include:\n - src/** correctly includes 'release' branch and 'src/**' path. trigger:\n branches:\n include:\n - release\n paths:\n exclude:\n - src/** excludes 'src/**' so it won't trigger on those files. trigger:\n branches:\n exclude:\n - release\n paths:\n include:\n - src/** excludes 'release' branch, so no trigger on it. trigger:\n branches:\n include:\n - main\n paths:\n include:\n - src/** triggers on 'main' branch, not 'release'.

3. Final Answer:

   trigger:\n branches:\n include:\n - release\n paths:\n include:\n - src/** -> Option A

4. Quick Check:

   Include branch and path filters to trigger correctly [OK]

Hint: Use both branches and paths include to filter triggers [OK]

Common Mistakes:

• Using exclude instead of include for paths
• Triggering on wrong branch
• Forgetting to specify paths filter