Seeking the thrill of transformative tech? Explore the art of designing and implementing DevOps solutions on Azure. Master the shift towards CI/CD, testing, and delivery, while preparing for the Designing and Implementing Microsoft DevOps Solutions exam!
YAML Pipelines in Azure DevOps are the foundation for automating continuous integration (CI) and continuous delivery (CD) workflows. A pipeline is defined in a YAML file and controls the entire process of building, testing, and deploying an application. The pipeline is built from three main layers. Steps are the smallest units of work and can be either scripts or tasks. Jobs are collections of steps that run in sequence on a single agent. Stages represent high-level phases of the pipeline, such as "Build" or "Deploy to Production," and each stage can contain multiple jobs. Variables and templates are the tools that make pipelines modular and reusable. Variables hold values that change between environments, like a connection string or a target URL, while templates let you define common logic once and reuse it across many pipelines.
A layered stack diagram showing the hierarchical structure of a YAML pipeline, from the overarching pipeline down through stages, jobs, and individual steps.
To create a new pipeline, you start by signing in to your Azure DevOps organization and navigating to the Pipelines section. You then select "New pipeline" and choose where your source code is stored, such as GitHub or Azure Repos Git. From there, you can either select a pre-built template or define your own custom logic in a YAML file. The YAML file lives in your repository alongside your code, so changes to the pipeline are version-controlled just like any other file.
A typical build pipeline for a .NET application shows how the layers fit together. The trigger field tells the pipeline to run automatically whenever changes are pushed to the main branch. The pool field specifies which type of virtual machine agent to use, in this case a Windows image. The steps section lists the tasks in order: first restore NuGet packages, then build the solution with MSBuild, and finally publish the build artifacts to a staging directory so they can be used later by a release pipeline.
When it is time to deploy to Azure, you add deployment tasks that target a specific Azure service. For example, the AzureWebApp task deploys a packaged application to an Azure App Service. This task requires two pieces of information: an azureSubscription that connects your Azure DevOps organization to your Azure subscription, and the appName of the target web app. The package input points to the artifact that was published in the build stage, so the build and deploy stages are linked through the artifact.
Using YAML pipelines brings three main advantages. Consistency ensures that the same build and deployment process runs in every environment, because the pipeline definition is the single source of truth. Modularity comes from templates and variables, which let you reuse pipeline logic across multiple projects without copying and pasting. Scalability means the pipeline can handle increasing workloads automatically, because Azure DevOps manages the agents and the queue. Together, these practices create robust, repeatable, and automated DevOps workflows.
Prepare and test your skills
Prepare and test your skills
Steps are the smallest units of work and can be either scripts or tasks. Jobs are collections of steps that run in sequence on a single agent. Stages represent high-level phases of the pipeline, such as Build or Deploy to Production, and each stage can contain multiple jobs.
Sign in to your Azure DevOps organization, navigate to the Pipelines section, select New pipeline, and choose where your source code is stored, such as GitHub or Azure Repos Git. From there, you can either select a pre-built template or define your own custom logic in a YAML file, which lives in your repository alongside your code.
The three main benefits are consistency, modularity, and scalability. Consistency ensures the same build and deployment process runs in every environment because the pipeline definition is the single source of truth. Modularity comes from templates and variables, enabling reuse of pipeline logic across multiple projects. Scalability means the pipeline can handle increasing workloads automatically, as Azure DevOps manages the agents and the queue.
Add a deployment task such as the AzureWebApp task, which requires an azureSubscription that connects your Azure DevOps organization to your Azure subscription and the appName of the target web app. The package input points to the artifact published in the build stage, linking the build and deploy stages through that artifact.
StudyCerts
StudyCerts