AZ-400 - Design and Implement Release Pipelines
1. Continuous Delivery (CD) Concepts
Continuous Delivery is the practice of keeping code in a deployable state at all times. Every change that passes automated testing is a release candidate. Continuous Deployment goes further by automatically deploying every validated change to production.
CD vs Continuous Deployment
Key Difference
Continuous Delivery means every change is ready to deploy but requires a manual approval step before going to production. Continuous Deployment automates the full pipeline from commit to production without manual intervention. Most organizations start with Continuous Delivery and evolve toward Continuous Deployment as confidence in their pipeline grows.
2. Azure Release Pipelines
Azure Release Pipelines (classic) provide a visual interface for defining deployment workflows with stages, approval gates, and artifact sources. Multi-stage YAML pipelines are the modern alternative that defines both build and release in a single YAML file.
Stages and Environments
Release Pipeline Structure
A classic release pipeline consists of: Artifacts (build outputs that trigger the release), Stages (Dev, QA, Staging, Production), Pre-deployment conditions (triggers, approvals, gates), Tasks (deployment steps within a stage), and Post-deployment conditions (approvals and gates after deployment). Each stage represents a target environment.
Approvals and Gates
Approval Workflows
Pre-deployment approvals require designated approvers to authorize deployment before it begins. Post-deployment approvals require sign-off after deployment completes. Approvers can be individual users or groups. Features include: timeout policies, sequential vs parallel approval order, and the ability for the deployer to approve their own deployments (configurable).
Gates
Gates are automated checks that run periodically until they pass or time out. Built-in gates include: Invoke Azure Function (call a function and check result), Query Azure Monitor alerts (ensure no active alerts), Invoke REST API (call an external endpoint), Query Work Items (ensure no open critical bugs), and Security and Compliance Assessment. Gates enable data-driven deployment decisions without manual intervention.
3. Deployment Groups
What Are Deployment Groups?
Deployment groups are logical sets of target machines with agents installed. They enable deploying to multiple servers (on-premises or cloud VMs) in parallel or rolling fashion. Each machine in a deployment group runs the Azure Pipelines agent and can be tagged (e.g., web, db, app) to target specific roles during deployment.
4. Containers and Docker
Docker Fundamentals
Docker Concepts
A Dockerfile defines how to build a container image layer by layer. Images are immutable templates for creating containers. Containers are running instances of images. Multi-stage builds use multiple FROM statements to create smaller production images by separating build-time and runtime dependencies.
Azure Container Registry (ACR)
ACR Features
ACR is a managed Docker registry service in Azure. Key features include: Geo-replication for multi-region deployments, ACR Tasks for automated image building on code commit or base image update, Content trust for image signing, Service tiers (Basic, Standard, Premium), and integration with AKS, App Service, and Azure Pipelines. ACR supports both Docker images and OCI (Open Container Initiative) artifacts.
Azure Container Instances (ACI)
ACI Overview
ACI provides serverless containers that can run without managing VMs or orchestrators. Use cases include burst workloads, short-lived tasks, CI/CD build agents, and event-driven processing. ACI supports container groups (multiple containers sharing a host, network, and lifecycle), similar to Kubernetes pods. ACI can be integrated with Azure Virtual Network for private networking.
Azure Kubernetes Service (AKS)
AKS Deploy from Azure Pipelines
AKS is a managed Kubernetes cluster. Azure Pipelines deploys to AKS using the KubernetesManifest task or HelmDeploy task. Deployment strategies include: Rolling updates (default), Blue-green (using multiple deployments with service switch), and Canary (using SMI or Kubernetes manifests). Azure Pipelines Environments can model AKS namespaces with approval gates.
5. Multi-Stage YAML Pipelines
Unified Build and Release
Multi-stage YAML pipelines combine build and deployment in a single YAML file. Each stage can depend on previous stages, have its own variables, and target different environments. Deployment jobs use the deployment keyword and can reference environments with approval checks defined in Azure DevOps. This provides full pipeline-as-code with version control and PR-based review of deployment changes.
Container Jobs
Container jobs run pipeline steps inside a Docker container, ensuring a consistent build environment regardless of the host agent. You specify the container image in the YAML file. This is useful for ensuring specific tool versions and avoiding agent configuration drift. Container jobs can pull images from ACR or Docker Hub.
← Back to AZ-400 Preparation Topics