Skip to content

Azure DevOps (Pipelines, Repos, Boards, Artifacts, GitHub Actions)

Scope

Azure CI/CD and DevOps tooling. Covers Azure Pipelines (multi-stage YAML, environments, approval gates), GitHub Actions integration, ACR Tasks, service connections (workload identity federation), agent pools, Azure Artifacts, and branch policies.

Checklist

  • [Critical] Choose CI/CD platform: Azure DevOps Pipelines for full Azure DevOps ecosystem integration (Boards, Repos, Artifacts, Test Plans) vs GitHub Actions for GitHub-native workflows with Azure deployment actions; both support YAML pipeline definitions and self-hosted runners/agents
  • [Recommended] Define Azure Pipelines YAML structure with multi-stage pipelines: stages for build, test, deploy-to-dev, deploy-to-staging, deploy-to-prod; use templates (extends, steps, jobs) for reusable pipeline components shared across repositories via template repositories
  • [Critical] Configure environments in Azure Pipelines with approval gates: manual approvals (single or multiple approvers with timeout), business hours checks, Azure Monitor alerts gate (deploy only when no active alerts), exclusive lock (prevent concurrent deployments to the same environment), and branch control (only deploy from main)
  • [Critical] Set up service connections for Azure deployments: workload identity federation (OIDC, recommended, no secret management) or service principal with client secret/certificate; scope service connections to specific resource groups or subscriptions using least-privilege RBAC
  • [Recommended] Configure Azure Container Registry (ACR) build tasks for container image building: ACR Tasks support Dockerfile builds, multi-step tasks (build, test, push), base image update triggers (auto-rebuild when base image changes), and scheduled builds; eliminates need for Docker daemon on build agents
  • [Recommended] Implement Bicep/ARM template deployment in pipelines: use AzureResourceManagerTemplateDeployment task with what-if preview in PR pipelines (shows planned changes without applying), incremental vs complete deployment mode, and parameter files per environment
  • [Optional] Use Azure Artifacts for package management: npm, NuGet, Maven, Python, and universal packages; upstream sources proxy public registries (npmjs.com, nuget.org) with cached packages for reliability; feed views (release, prerelease) for package promotion
  • [Critical] Configure branch policies in Azure Repos: require pull requests with minimum reviewers (auto-include by path), build validation (CI must pass before merge), comment resolution, linked work items, and merge strategy (squash, rebase, merge commit)
  • [Recommended] Design agent pool strategy: Microsoft-hosted agents (zero maintenance, clean VM per job, limited to 60 minutes by default) vs self-hosted agents (custom software, network access to private resources, persistent caches, unlimited job time); use scale set agents for auto-scaling self-hosted pools
  • [Critical] Implement secret management in pipelines: Azure Key Vault-linked variable groups for runtime secret injection, pipeline variable secrets (masked in logs), and never store secrets in YAML files or repository; use managed identity on self-hosted agents for Key Vault access
  • [Optional] Set up Azure Boards integration: link commits, PRs, and pipeline runs to work items for traceability; use AB#1234 syntax in commit messages for automatic linking; configure deployment status on work items showing which environment contains each change
  • [Optional] Configure pipeline caching for build performance: cache npm/NuGet/pip packages, Docker layer caching, compiled output caching; use Cache@2 task with key based on lock file hash; caching can reduce build times by 50-80% for dependency-heavy projects
  • [Recommended] Implement infrastructure-as-code deployment patterns: Bicep modules for Azure resources, Terraform with Azure backend (storage account state), or Pulumi; use separate pipelines or stages for infrastructure and application deployment with proper dependency ordering

Why This Matters

CI/CD pipeline design directly impacts deployment velocity, reliability, and security posture. Poorly designed pipelines lead to slow feedback loops (30+ minute builds), manual deployment errors, secret leaks in logs, and inability to roll back. Azure DevOps and GitHub Actions both provide enterprise-grade CI/CD, but the choice affects team workflow, integration depth, and operational patterns.

Service connection security is critical: over-privileged service principals with subscription-level Contributor access are a common finding in security audits. Workload identity federation eliminates secret rotation risk entirely. Environment approval gates prevent accidental production deployments but must be balanced against deployment velocity -- too many gates slow delivery without proportional risk reduction.

ACR Tasks is underutilized: most teams run Docker builds on CI agents, requiring Docker daemon access and consuming agent resources. ACR Tasks offloads builds to Azure infrastructure, supports automatic rebuilds when base images update (critical for security patches), and integrates natively with ACR for zero-network-hop push.

Common Decisions (ADR Triggers)

  • Azure DevOps vs GitHub Actions -- Azure DevOps provides an integrated suite (Boards, Repos, Pipelines, Artifacts, Test Plans) with mature enterprise features (audit logs, organization policies, IP restrictions). GitHub Actions provides a simpler YAML syntax, larger marketplace of community actions, and native integration with GitHub PRs and issues. Use Azure DevOps for enterprises already invested in the Microsoft ecosystem or needing integrated project management. Use GitHub Actions for teams using GitHub for source control, open-source projects, or teams preferring a code-first approach.
  • Microsoft-hosted vs self-hosted agents -- Microsoft-hosted agents provide clean VMs per job, zero maintenance, and pre-installed tools, but lack network access to private resources (VNet-isolated databases, on-premises systems) and have fixed specs (2 vCPU, 7 GB RAM). Self-hosted agents provide custom configurations, private network access, persistent caches, and unlimited job duration, but require VM/container management, patching, and scaling. Use Microsoft-hosted for standard builds. Use self-hosted for private resource access, custom tooling, or performance-sensitive builds.
  • YAML pipelines vs Classic (GUI) pipelines -- YAML pipelines are version-controlled, reviewable in PRs, reusable via templates, and support multi-stage deployments. Classic pipelines provide a visual designer but are not version-controlled and harder to audit. YAML is the recommended approach for all new pipelines. Classic pipelines are in maintenance mode with no new features.
  • Bicep vs Terraform vs ARM templates for IaC -- Bicep is Azure-native, compiles to ARM, has first-class VS Code support, and requires no state management. Terraform is cloud-agnostic, has a massive provider ecosystem, and provides plan/apply workflow with state management (requires storage account backend). ARM templates are verbose JSON and largely superseded by Bicep. Use Bicep for Azure-only deployments. Use Terraform for multi-cloud or teams with existing Terraform expertise.
  • Monorepo vs multi-repo pipeline strategy -- Monorepo uses path-based triggers (trigger on changes to src/service-a/**) with pipeline templates for each service. Multi-repo uses separate pipelines per repository with cross-repo triggering via resources. Monorepo simplifies dependency management and atomic cross-service changes. Multi-repo provides clearer ownership boundaries and independent release cycles.
  • Azure Artifacts vs external package registries -- Azure Artifacts integrates natively with Azure Pipelines, supports upstream sources for proxying public registries, and provides feed-level access control. External registries (JFrog Artifactory, Sonatype Nexus, GitHub Packages) may provide richer features for specific ecosystems. Use Azure Artifacts for simplicity within Azure DevOps. Use external registries for multi-platform organizations or specific feature needs.

Reference Architectures

Multi-Stage Deployment Pipeline

Azure Repos (main branch protected with policies) -> PR trigger: build, unit test, Bicep what-if preview as PR comment. Merge trigger: build stage (compile, test, publish artifact) -> deploy-dev (automatic, AzureResourceManagerTemplateDeployment + app deployment) -> deploy-staging (automatic, integration tests gate) -> deploy-prod (manual approval from release-approvers group, business hours gate, Azure Monitor no-alerts gate). Variable groups per environment linked to Key Vault. Pipeline templates in a shared template repository.

Container Application CI/CD

GitHub repository -> GitHub Actions workflow: build Docker image -> push to ACR -> deploy to AKS. ACR Tasks configured for base image update triggers (auto-rebuild when base image like node:18-alpine is updated). Workload identity federation for GitHub Actions OIDC authentication to Azure. Helm chart deployment with environment-specific values files. Canary deployment strategy using Kubernetes service mesh or AKS deployment strategy.

Infrastructure and Application Separation

Infrastructure pipeline: Bicep modules in infra/ directory, triggered on infra file changes. Deploys shared resources (VNet, Key Vault, ACR, AKS cluster) with what-if validation. Application pipeline: triggered on src/ changes, depends on infrastructure pipeline completion. Builds application, pushes to ACR, deploys to AKS using Helm. Both pipelines use the same environment approval gates. Terraform state stored in Azure Storage with state locking.

GitOps with Azure DevOps and AKS

Azure Repos hosts Kubernetes manifests (or Helm charts) in a config repository. Application CI pipeline builds and pushes images to ACR, then updates image tag in config repo via automated PR. Flux or Argo CD on AKS watches config repo and reconciles cluster state. Azure DevOps Boards linked to PRs for change traceability. Pipeline gates validate manifests with kubeval/kubeconform before merge.

See Also

  • general/ci-cd.md -- General CI/CD patterns and pipeline design
  • providers/azure/bicep.md -- Bicep IaC deployment within Azure Pipelines
  • providers/azure/containers.md -- AKS and ACR as deployment targets for container CI/CD
  • providers/azure/security.md -- Key Vault integration and workload identity for pipeline secrets