AZ-400 - Design and Implement Build Pipelines
1. Continuous Integration (CI) Concepts
Continuous Integration is the practice of frequently merging code changes into a shared repository, with each merge automatically verified by building the project and running automated tests. CI enables teams to detect integration issues early and maintain a releasable codebase.
CI Best Practices
Key CI Principles
Maintain a single source repository. Automate the build and make it self-testing. Every commit should trigger a build. Keep the build fast (under 10 minutes is ideal). Test in a clone of the production environment. Make it easy for anyone to get the latest deliverables. Everyone can see build results and status.
2. Azure Pipelines
Azure Pipelines is the CI/CD service in Azure DevOps that supports building, testing, and deploying code from any repository (Azure Repos, GitHub, Bitbucket, etc.) to any target platform.
YAML Pipelines
Pipeline Structure
YAML pipelines define the build process as code. The hierarchy is: Pipeline → Stages → Jobs → Steps (tasks and scripts). A trigger section defines when the pipeline runs (e.g., on push to main). A pool section specifies which agent pool to use. Variables can be defined inline, in variable groups, or linked from Azure Key Vault.
YAML vs Classic Pipelines
YAML pipelines are defined in code, version-controlled, support templates and reuse, and are the recommended approach. Classic pipelines use a visual designer in the Azure DevOps portal. YAML pipelines support multi-stage definitions (build + deploy in one file), while classic separates build and release definitions. Microsoft recommends YAML for all new pipelines.
Pipeline Triggers
Trigger Types
CI triggers run on code push to specified branches. PR triggers run when a pull request targets specified branches. Scheduled triggers run on a cron schedule. Pipeline triggers run when another pipeline completes. Branch filters and path filters allow fine-grained control over which changes trigger a build.
3. Build Agents
Agents are the compute resources that run pipeline jobs. Azure Pipelines provides both Microsoft-hosted and self-hosted agents.
Agent Types
Microsoft-Hosted vs Self-Hosted Agents
Microsoft-hosted agents are fully managed VMs provisioned fresh for each job. They support Windows, Ubuntu, and macOS images. Each job gets a clean environment, so no state persists between runs. Self-hosted agents run on your own infrastructure (VMs, containers, on-premises machines). They are ideal for: using specialized software, accessing private networks, reusing tool installations for faster builds, and running builds that exceed the 6-hour time limit of hosted agents.
Agent Pools
Agent pools are collections of agents. The Azure Pipelines pool contains Microsoft-hosted agents. Organization-scoped pools are shared across projects. Project-scoped pools are available only within a specific project. Demands and capabilities match jobs to agents that satisfy their requirements (e.g., a job requiring Java 17 matches an agent with that capability).
4. Unit Tests and Code Coverage
Running Tests in Pipelines
Test Integration
Azure Pipelines natively supports test results from popular frameworks: JUnit (Java), NUnit/xUnit/MSTest (.NET), pytest (Python), and Mocha/Jest (JavaScript). Test results are published using the PublishTestResults task and displayed in the Tests tab of the pipeline run. Flaky test detection can be enabled to identify unreliable tests.
Code Coverage
Code coverage measures the percentage of code exercised by tests. Azure Pipelines supports coverage tools like Cobertura and JaCoCo (Java), Istanbul/nyc (JavaScript), and Coverlet (.NET). The PublishCodeCoverageResults task publishes coverage reports viewable in the Code Coverage tab. Teams typically set minimum coverage thresholds (e.g., 80%) as quality gates.
5. GitHub Actions
GitHub Actions Overview
GitHub Actions is GitHub's built-in CI/CD platform. Workflows are defined in YAML files under .github/workflows/. Workflows contain jobs, and jobs contain steps (actions or shell commands). GitHub provides thousands of pre-built actions in the GitHub Marketplace. GitHub Actions supports matrix builds, caching, artifacts, and environment secrets.
Azure Pipelines vs GitHub Actions
Both support YAML-based pipeline definitions. Azure Pipelines uses task references, GitHub Actions uses action references. Azure Pipelines supports deployment environments with approval gates natively. GitHub Actions uses environments with protection rules. Azure Pipelines has deeper integration with Azure DevOps services, while GitHub Actions integrates natively with GitHub features.
6. Jenkins Integration
Jenkins with Azure DevOps
Jenkins can be integrated with Azure DevOps using the Azure DevOps plugin for Jenkins and the Jenkins service connection in Azure DevOps. This enables scenarios where existing Jenkins infrastructure handles builds while Azure DevOps manages work items and releases. Azure Pipelines can trigger Jenkins jobs and wait for their completion.
7. SonarCloud and Code Quality
SonarCloud Integration
SonarCloud is a cloud-based code quality and security analysis service. It integrates with Azure Pipelines using the SonarCloudPrepare, SonarCloudAnalyze, and SonarCloudPublish tasks. SonarCloud detects bugs, vulnerabilities, code smells, and security hotspots. Quality gates define thresholds that must pass before code is merged. For self-hosted environments, SonarQube provides the same capabilities.
8. Pipeline Caching
Cache Task
The Cache task in Azure Pipelines stores and restores files between pipeline runs, reducing build times. Common use cases include caching NuGet packages, npm node_modules, Maven .m2 repositories, and pip packages. The cache key is based on a hash of lock files (e.g., package-lock.json) so the cache is invalidated when dependencies change.
← Back to AZ-400 Preparation Topics