# Build pipeline

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/build-pipeline

## Quick definition

A build pipeline is an automated process that takes your code and turns it into a working program. It runs checks like compiling the code and running tests to make sure everything works. This happens automatically whenever you update your code. It helps teams catch bugs early and deliver software faster.

## Simple meaning

Imagine you are baking a cake from a recipe. Your recipe is like the code, and the final cake is the software that people can use. A build pipeline is like having an automated kitchen helper that follows the recipe step by step. First, it mixes the dry ingredients (compiling the code). Then it adds the wet ingredients (linking libraries). It checks if the batter is too runny (running unit tests). It pours the batter into a pan (packaging the application). Finally, it bakes the cake for the right time (creating the final installable file). 

 If the helper finds a problem at any step, like the batter is too thick, it stops and tells you what went wrong. You fix the recipe and try again. Without this helper, you would have to do all these steps manually every time you baked, which is slow and error-prone. 

 In software development, teams write code in small pieces. They need to combine all those pieces, make sure they work together, and create a single package that can be installed on a server or a phone. The build pipeline automates this whole process. It runs every time someone changes the code, so problems are found immediately. This is called continuous integration, and it is a core practice in modern DevOps. A good build pipeline saves hours of manual work and gives developers confidence that their changes are safe.

## Technical definition

A build pipeline is a structured, automated workflow that transforms source code into a build artifact, typically a binary, package, or container image. It is a fundamental component of Continuous Integration (CI) practices. The pipeline is defined as a set of stages, jobs, and steps, usually declared in a YAML file (e.g., azure-pipelines.yml for Azure DevOps). Each stage represents a major phase, such as compilation, testing, packaging, and artifact publishing. 

 The pipeline triggers automatically on code changes pushed to a version control system like Git. The agent, which is a server or container, runs the pipeline steps. The agent pulls the latest source code, restores dependencies from package managers (e.g., NuGet, npm, Maven), and compiles the code using build tools like MSBuild, dotnet build, or Gradle. Unit tests are executed, and code coverage reports are generated. If any step fails, the pipeline stops and alerts the team. 

 On success, the pipeline may run additional quality gates like static code analysis (SonarQube), security scanning, and integration tests. The final output is a build artifact, which is stored and versioned in a artifact repository (e.g., Azure Artifacts, JFrog Artifactory). This artifact can then be deployed to staging or production environments in a subsequent release pipeline. In the context of the AZ-400 exam, build pipelines are typically implemented using Azure Pipelines. Key concepts include triggers, variables, multiple jobs, agent pools, and pipeline caching. Understanding how to configure and optimize build pipelines is critical for automating software delivery and maintaining code quality.

## Real-life example

Think of a build pipeline like the automated assembly line at a car factory. The raw materials are the car parts (your source code files). Without an assembly line, workers would have to manually build each car from scratch, which would take weeks and be prone to mistakes. The assembly line automates the process. 

 First, the chassis is placed on the line. At the first station, the engine is installed. At the next station, the wheels are attached. Each station checks if the previous step was done correctly. If a wheel is missing, the line stops and an alarm sounds. This is like the build pipeline stopping because of a compilation error. 

 At the end of the line, the finished car rolls off, ready to be painted and shipped. This is the build artifact. If the factory changes the design of the engine, the assembly line updates automatically for the next car. Similarly, when a developer changes the code, the build pipeline runs again with the new instructions. 

 The key benefit is speed and consistency. The same steps are followed every single time, so every build is reproducible. No manual steps are skipped. This ensures that the software is always built the same way, whether it is for testing or for production. Without a build pipeline, developers would have to manually compile, test, and package their software, which is slow, boring, and error-prone.

## Why it matters

In a professional IT environment, software is built by teams of developers working on many files simultaneously. Without a build pipeline, integrating all those changes would be a nightmare. Every developer would have to manually compile the entire codebase and run tests before submitting their changes. This is impractical and leads to integration hell, where problems only surface when you try to combine everyone's work. 

 A build pipeline automates all of this. As soon as a developer pushes code to the shared repository, the pipeline runs. It verifies that the code compiles, that all tests pass, and that the code meets quality standards. If something breaks, the team knows immediately. This feedback loop is critical for agile development and continuous delivery. 

 Many organizations have strict compliance and auditing requirements. A build pipeline provides an immutable record of exactly how each build was created. You can see which source code version was used, which tools ran, and who triggered the build. This traceability is essential for regulated industries like finance and healthcare. 

build pipelines save significant time and money. Manual builds can take hours of a developer's day. Automation frees them to focus on writing code. It also reduces the risk of human error, such as forgetting to run a test or using the wrong compiler settings. In short, a build pipeline is the backbone of modern software development, enabling teams to deliver high-quality software quickly and reliably.

## Why it matters in exams

The build pipeline is a central topic in the Microsoft Azure DevOps Solutions (AZ-400) exam. This exam tests your ability to design and implement DevOps processes using Azure DevOps. Build pipelines are explicitly covered in the section 'Design and Implement Build and Release Pipelines', which is a major part of the exam. You will be expected to understand the components of a pipeline, including triggers, variables, agents, stages, jobs, tasks, and artifact publishing. 

 Exam questions often present a scenario where you need to choose the correct YAML configuration for a specific requirement. For example, you might be asked how to set up a trigger so that the pipeline runs only when changes are made to the main branch. Or you might need to configure a variable to be used in multiple pipeline stages. Understanding the difference between process variables, system variables, and secret variables is crucial. 

 Another common objective is optimizing build pipelines. Questions may ask about using pipeline caching to speed up dependency restoration, or about using parallel jobs to run tests faster. You may also need to know how to integrate security scanning tools like WhiteSource or SonarQube into the pipeline. 

 The exam also covers self-hosted vs. Microsoft-hosted agents. You should know when to use each, how to set up agent pools, and how to configure agent demands. There are also questions about multi-stage pipelines, where the same YAML file defines both build and release steps. This is a key concept in the newer YAML-based pipelines. 

 Finally, troubleshooting is a common question type. You might be given a failed pipeline log and asked to identify the cause, such as a missing dependency, an incorrect variable value, or a wrong agent configuration. Mastering build pipelines is not optional for passing AZ-400; it is a core requirement.

## How it appears in exam questions

Build pipeline questions on the AZ-400 exam appear in several distinct patterns. The first type is scenario-based. You are given a description of a team's workflow and asked to implement a pipeline that meets specific requirements. For example, a team wants the pipeline to automatically build and run unit tests whenever a pull request is created, but only for the release branch. You would need to configure a pull request trigger in the YAML file. 

 The second type is configuration questions. These may give you a snippet of YAML code and ask you to identify an error or a missing element. For example, they might omit the 'trigger' section, or they might incorrectly define a variable using the wrong syntax ($(VAR) vs. $[variables.Var]). You need to know the correct YAML syntax for Azure Pipelines. 

 The third type is optimization and best practices. A question might ask which strategy to use to reduce build time. The correct answer might be 'pipeline caching' to cache npm packages or NuGet packages. Another example is choosing between multiple jobs (parallel execution) vs. a single job, or between using a hosted agent vs. a self-hosted agent with specific software installed. 

 Troubleshooting questions present a failed build log. You might see an error like 'Project file not found' or 'The term 'dotnet' is not recognized'. You need to diagnose the cause. Common fixes include ensuring the correct tasks are installed, that the agent has the required tools, or that the build configuration is correct. 

 Finally, there are concept questions that ask about the order of pipeline execution, the difference between a build pipeline and a release pipeline, or the purpose of specific tasks like 'PublishBuildArtifacts' or 'CopyFiles'. Being familiar with the standard task catalog in Azure DevOps is helpful. Overall, you need both theoretical knowledge of CI/CD and practical experience with Azure Pipelines to succeed.

## Example scenario

You are a DevOps engineer for a company called 'HealthyFoods Inc.' that builds a mobile app for meal planning. The development team uses Git and Azure Repos. They want to automate the process of building the app and running tests every time someone changes the code. They ask you to set up a build pipeline. 

 The app is built with .NET MAUI and uses a SQLite database. The source code is in a single repository with two main components: the app code and a testing project. The team wants the pipeline to run on every push to the 'main' branch and on every pull request targeting 'main'. 

 You create an azure-pipelines.yml file. You define the trigger as 'main'. You configure a pool to use the 'windows-latest' agent because the .NET MAUI build requires Windows. The pipeline has three stages. First, you run a 'dotnet restore' task to restore NuGet packages. Second, you run 'dotnet build' with the Release configuration. Third, you run 'dotnet test' on the test project with code coverage enabled. 

 If the build fails because of a syntax error, the pipeline stops and the team gets a notification. If the build succeeds, the pipeline publishes the app package (an .msi file) as a build artifact. The artifact is stored in Azure Artifacts. Later, a release pipeline picks up this artifact and deploys it to internal test devices. 

 This scenario is typical for the AZ-400 exam. You need to demonstrate that you can set up the YAML correctly, choose the right agent, configure the steps, and handle failures. You also need to know how to work with variables, caching, and task dependencies.

## Common mistakes

- **Mistake:** Using the wrong agent pool (e.g., Ubuntu for a .NET Framework build that requires Windows).
  - Why it is wrong: The build will fail because the agent does not have the required tools or operating system to compile the code.
  - Fix: Always match the agent pool to the build requirements. Use 'windows-latest' for .NET Framework or MAUI builds, 'ubuntu-latest' for cross-platform builds.
- **Mistake:** Not defining a trigger, so the pipeline never runs automatically on code pushes.
  - Why it is wrong: The pipeline must be manually triggered every time, defeating the purpose of continuous integration.
  - Fix: Add a 'trigger' section to the YAML file specifying the branches that should trigger the pipeline, e.g., 'trigger: [main]'.
- **Mistake:** Hard-coding sensitive information like passwords or API keys directly in the YAML file.
  - Why it is wrong: This exposes secrets in the source code repository, which is a security risk.
  - Fix: Use Azure DevOps pipeline variables (set as 'secret') and reference them using '$(variableName)' in the YAML.
- **Mistake:** Forgetting to restore dependencies before building, leading to 'package not found' errors.
  - Why it is wrong: The build task cannot find the required libraries and fails immediately.
  - Fix: Always include a 'dotnet restore' or 'npm install' step before the build step in the pipeline.
- **Mistake:** Not publishing the build artifact, so the output is lost after the pipeline finishes.
  - Why it is wrong: There is no deployable package for downstream release pipelines or manual deployment.
  - Fix: Add a 'PublishBuildArtifacts' task at the end of the pipeline to store the built files.

## Exam trap

{"trap":"Choosing a 'Classic' release pipeline when the question asks for a multi-stage build pipeline defined in YAML.","why_learners_choose_it":"Learners often think of release pipelines as separate from build pipelines, but modern Azure DevOps encourages combining them in a single YAML file for better traceability and efficiency.","how_to_avoid_it":"Remember that the exam emphasizes YAML-based multi-stage pipelines. If the question describes a single pipeline with both build and deployment stages, the answer should use YAML stages, not separate Classic release definitions."}

## Commonly confused with

- **Build pipeline vs Release pipeline:** A build pipeline creates the build artifact (e.g., a .exe or .zip file). A release pipeline takes that artifact and deploys it to environments like staging or production. They are sequential steps in a CI/CD workflow. You can combine them in a single multi-stage YAML pipeline. (Example: Build pipeline: compile code and run tests -> release pipeline: install the .exe on a server.)
- **Build pipeline vs Continuous Integration (CI):** CI is the practice of automatically building and testing code changes frequently. The build pipeline is the technical tool that implements CI. CI is the broader philosophy, while the build pipeline is the concrete set of automated steps. (Example: CI says 'automate the build process.' The build pipeline is the automation script (YAML file) that does the work.)
- **Build pipeline vs Build agent:** A build agent is the machine (server or container) that executes the build pipeline steps. The pipeline is the definition of what to do; the agent is the worker that does it. You can have multiple agents in a pool to run builds in parallel. (Example: The pipeline is like a recipe card. The agent is the chef who follows the recipe to cook the meal.)
- **Build pipeline vs Build artifact:** A build artifact is the output of the build pipeline, such as a compiled .dll, a NuGet package, or a container image. The artifact is stored and used later. The pipeline is the process; the artifact is the result. (Example: The pipeline bakes the cake (artifact). The cake is then served to customers (deployed).)

## Step-by-step breakdown

1. **Trigger** — The pipeline automatically starts when a specific event occurs, such as a code push to a branch or a pull request being created. This ensures builds happen without manual intervention.
2. **Source Code Checkout** — The agent pulls the latest version of the source code from the version control system (e.g., Git). It retrieves all files needed for the build.
3. **Restore Dependencies** — The pipeline downloads external libraries and packages that the code relies on, such as NuGet packages or npm modules. This step ensures the build environment has everything needed.
4. **Compile/Build** — The source code is compiled into executable binaries or intermediate files using a build tool (e.g., MSBuild, dotnet build, gcc). This step transforms human-readable code into machine code.
5. **Run Tests** — Unit tests and integration tests are executed to verify the code works correctly. If any test fails, the pipeline stops and alerts the team, preventing bad code from moving forward.
6. **Publish Artifacts** — The built binaries, configuration files, and any other output are packaged together and stored as a build artifact. This artifact is then available for deployment or further testing.

## Practical mini-lesson

A build pipeline is not just a script that runs a compiler. In real-world DevOps, it is a sophisticated system that orchestrates multiple tasks, manages secrets, and provides feedback. To set up a build pipeline in Azure DevOps, you typically work with YAML files stored in the repository. This is called 'configuration as code' and is the preferred method for the AZ-400 exam. 

 Start by creating a file named azure-pipelines.yml at the root of your repository. The basic structure includes a 'trigger' section, a 'pool' section (agent type), and a 'steps' section. Steps can be inline tasks or references to pre-built tasks from the Azure Pipelines task catalog. Common tasks include 'DotNetCoreCLI@2' for .NET builds, 'Npm@1' for Node.js, and 'CopyFiles@2' for moving files. 

 Variables are a critical part. You can define custom variables in the YAML, but more importantly, you can use library variable groups to securely store secrets like API keys or database connection strings. In the pipeline, reference a variable using $(VariableName). For secret variables, they are masked in logs automatically. 

 Pipeline caching is a powerful feature to speed up builds. For example, you can cache the 'node_modules' folder or the NuGet packages folder. This means that if the dependencies have not changed, the agent restores them from cache instead of downloading everything again, which can save minutes per build. 

 Another practical consideration is the agent pool. Microsoft-hosted agents are convenient and maintained by Microsoft, but they have a limited set of pre-installed software and have a timeout. Self-hosted agents give you full control and can run longer, but you must maintain them. For builds requiring specific hardware or proprietary tools, self-hosted agents are necessary. 

 What can go wrong? Common issues include agents running out of disk space, dependencies not being restored due to network issues, or build scripts failing because of environment differences (e.g., Windows vs. Linux). Always test your pipeline on a development branch before applying it to main. 

 Professionals often use multi-stage pipelines where the build stage publishes an artifact, and a later stage deploys it to an environment. This is achieved by adding 'stages' to your YAML. Each stage can have its own variables, agents, and conditions. This approach provides a complete CI/CD workflow in a single file, which is exactly what the AZ-400 exam tests.

## Memory tip

Think 'BRTP' for the order: Build -> Restore -> Test -> Publish. Remember: 'Before Releasing, Test Packages'.

## FAQ

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

A build pipeline compiles source code and creates a build artifact. A release pipeline takes that artifact and deploys it to environments like staging or production. Modern Azure DevOps allows combining both in a single multi-stage pipeline.

**Do I need to write YAML for a build pipeline?**

Azure DevOps supports both Classic Editor (UI-based) and YAML pipelines. The exam and industry prefer YAML because it is version-controlled, repeatable, and easier to maintain.

**What is a build artifact?**

A build artifact is the output of the build pipeline, such as compiled binaries, a .zip file, or a container image. It is stored and can be used by release pipelines for deployment.

**Can I run tests in a build pipeline?**

Yes, running unit tests and integration tests is a standard step in most build pipelines. It is a key part of continuous integration to catch bugs early.

**How do I handle secret variables in a pipeline?**

Define them as secret variables in the pipeline settings or in a variable group. Reference them in YAML using $(variableName). They are masked in logs and never exposed.

**What is pipeline caching?**

Pipeline caching saves frequently used files like dependencies between runs, speeding up subsequent builds. It is useful for large package caches like 'node_modules' or 'NuGet packages'.

**What are triggers in a build pipeline?**

Triggers define when the pipeline runs automatically. Common triggers include CI triggers (on code push to a branch) and PR triggers (on pull request creation).

## Summary

The build pipeline is an automated process that compiles source code, runs tests, and creates a deployable artifact. It is the foundation of continuous integration (CI) and is a core concept in the Azure DevOps AZ-400 exam. Understanding how to configure triggers, variables, agents, and steps in YAML is essential for passing the exam. 

 In practice, build pipelines save development teams countless hours and reduce errors by automating repetitive tasks. They provide fast feedback on code quality and ensure that every change is verified. Modern build pipelines are defined as code, typically in YAML, which makes them version-controlled and repeatable. 

 For certification candidates, the key takeaway is to gain hands-on experience with Azure Pipelines. Learn to write YAML from scratch, understand the difference between stages, jobs, and steps, and practice troubleshooting failures. The exam will test your ability to design efficient, secure, and reliable build pipelines. Mastery of this topic is not optional for DevOps professionals aiming for the AZ-400 certification.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/build-pipeline