Branch and Event Triggers
You can control when pipelines run to avoid unnecessary builds. Branch triggers let you specify which branches (like main or release/*) should start a pipeline. Event triggers determine what kind of GitHub activity causes the run, such as code pushes or pull requests. When both the branch and event conditions match, the pipeline runs automatically.
Security and Access Control
Keeping the integration secure involves managing permissions. The service connection should have only the minimum permissions needed, like read access to code. Branch protection policies add another layer by requiring pull request reviews or successful pipeline runs before code can be merged. Pipeline status checks ensure builds must pass before merging, preventing broken code from reaching protected branches.
Develop and Implement Pipeline Trigger Rules
Continuous Integration Triggers
A continuous integration trigger automatically starts a pipeline run every time a developer pushes code changes. This provides immediate feedback if new code breaks the build. In a YAML pipeline, you configure this with the trigger keyword, specifying which branches to monitor.
Scheduled Triggers
Scheduled triggers run pipelines at specific times, like nightly, for routine tasks such as security scans or cleanup. You configure these in YAML using the schedules keyword with cron syntax, so the system manages the timing automatically.
Pull Request Triggers
A pull request trigger runs a pipeline to validate code changes before they merge into a target branch. This acts as a quality gate. You configure it with the pr keyword in YAML, and teams can require a successful run before a merge is allowed.
Pipeline Resource Triggers
Pipeline resource triggers chain pipelines together. One pipeline can start automatically after another finishes. You set this up by declaring a resource dependency under resources.pipelines in your YAML. When the upstream pipeline reaches a completed state, the downstream pipeline begins.
Branch and Path Filters
Branch and path filters give granular control to prevent unnecessary runs and save costs. You add branches and paths attributes under your trigger definitions. For example, a pipeline can run only when files in a specific folder on the main branch are changed.
Develop Pipelines by Using YAML
Key Concepts
YAML Pipelines in Azure DevOps automate CI/CD workflows. A pipeline is defined in a YAML file and controls building, testing, and deploying. The structure has three layers: Steps are individual tasks or scripts. Jobs are sequences of steps that run on a single agent. Stages are high-level phases like "Build" or "Deploy," and can contain multiple jobs. Variables hold values that change between environments, and templates let you reuse common pipeline logic.
Setting Up a Pipeline
To create a pipeline, you sign into Azure DevOps, select "New pipeline," and choose your code repository. You can then use a template or write your own YAML file, which is stored in your repository and version-controlled with your code.
Example Build Pipeline
A typical build pipeline for a .NET app shows the layers. The trigger field runs the pipeline on pushes to main. The pool field selects a Windows agent. The steps section lists tasks in order: restore packages, build the solution, and publish artifacts for later use.
Deploying to Azure
To deploy, you add tasks targeting Azure services. For example, the AzureWebApp task deploys to an Azure App Service. It needs an azureSubscription connection and the target appName, and uses the artifact published in the build stage.
Design and Implement a Strategy for Job Execution Order, Including Parallelism and Multi-Stage Pipelines
Analyze Job Dependencies
You control the flow between jobs using if conditions. These let you decide the next step based on whether a previous step succeeded or failed. For example, you can run an error-handling step only when a prior activity fails.
Stages are major checkpoints. You connect them using conditions like Upon Completion, so the next stage only runs if the previous one finishes as expected. This ensures the pipeline stops early if something critical fails, saving time and resources.
Optimize Execution Conditions for Efficiency
Running multiple jobs at the same time, called parallel task execution, reduces total pipeline time. You can use job matrices and resource limits to run activities on different agents simultaneously. Patterns like Try-Catch-Proceed let the pipeline handle errors without stopping everything. Steps that must always run, like cleanup, can be connected via UponFailure paths.
Apply Common Patterns
Building robust pipelines means planning for errors. Place generic error-handling jobs at the end to catch unexpected issues. When a task fails, a logging or cleanup job should run automatically to record details and clean up resources. Connecting failure paths directly to error-handling jobs keeps the process reliable and maintainable.
Develop and Implement Complex Pipeline Scenarios, Such as Hybrid Pipelines, VM Templates, and Self-Hosted Runners or Agents
Combining Azure and On-Premises Resources
Hybrid pipelines create a single workflow using both Azure resources and your own on-premises computers. You write YAML definitions that run tasks in both places. This lets you keep sensitive tasks on your local network while using Azure cloud services for other parts, maintaining consistent CI/CD across different environments.
Using VM Templates for Build Agents
You can use Azure DevTest Labs to create virtual machines (VMs) that act as build agents. These VMs are made from preconfigured ARM templates that install all necessary software. This gives teams a private, production-like environment for safe testing and parallel builds. The lab manages the VM lifecycle, starting them for builds and shutting them down to save costs.
Setting Up and Securing Self-Hosted Agents
A self-hosted agent is software you install on your own VM, in Azure or on-premises. You register these agents to an agent pool in Azure Pipelines. To secure them, you connect them to Azure using a service connection backed by a service principal or managed identity. This lets the agent authenticate and follow your organization's security rules (RBAC) when accessing Azure resources.
Building the Pipeline with YAML
To create a hybrid pipeline, you write YAML with tasks that use tools like the Azure CLI. A task might create a new VM to act as a self-hosted agent and add it to a pool. Another task might use an Azure Resource Manager connection to deploy infrastructure from an ARM template. This builds a pipeline that scales agent capacity and operates securely across cloud and on-premises boundaries.
Create Reusable Pipeline Elements, Including YAML Templates, Task Groups, Variables, and Variable Groups
YAML Templates
YAML templates let you define reusable pieces of pipeline configuration. When you add parameters to a template, you can adapt it for different scenarios without copying code. This provides modularity by breaking large pipelines into smaller sections, consistency by ensuring every pipeline follows the same standards, and maintainability because you update the template in one place and all referencing pipelines get the change.
Task Groups
Task groups are collections of tasks that perform a specific function, like running tests and publishing artifacts. By grouping related tasks, you can reuse the entire group as a single step across many pipelines. This encapsulates logic, promotes reuse, and simplifies maintenance by reducing repetitive configurations.
Variables and Variable Groups
Variables and variable groups store values that change, like secrets, connection strings, or version numbers. They enable secure data management by keeping sensitive information out of the pipeline code. They allow dynamic configuration so the pipeline uses different settings for development versus production. They provide consistency by using the same variable names and values across multiple pipelines.
Using Reusable Components in Pipelines
You use these components by referencing YAML templates in your pipeline definitions, calling task groups within stages, and linking variables and variable groups to environments. This combination ensures modular, consistent, and maintainable workflows across Azure DevOps.
Design and Implement Checks and Approvals by Using YAML-Based Environments
Integrating Service Connections and Environment Types
To control deployments, YAML pipelines use environments and approvals. A pipeline needs a service connection (like an Azure Resource Manager connection) to authenticate with Azure. Environments define where code is deployed (like Sandbox or WebApp) and are linked to specific Azure subscriptions and permissions, creating clear security boundaries.
Implementing Automated Gates and Checks
Pipelines use automated pre-deployment and post-deployment gates to validate application health and compliance. These gates run scripts or tools within the pipeline steps. For example, a script might check a web endpoint's health and fail the deployment if the response is not Healthy.
Managing Manual Approvals and Security Policies
Beyond automated checks, pipelines can require manual approval. Teams configure reviewers within an environment's checks, halting the deployment until authorized users sign off. This creates a control boundary where code cannot flow to sensitive environments without explicit, logged approval from stakeholders.
StudyCerts
StudyCerts