Module 11: Enterprise Patterns, IaC & AI Integration

Enterprise Azure DevOps

Scaling Azure DevOps from a single team to an entire enterprise — 100 teams, 800 developers, dozens of repositories, and multiple products — is a fundamentally different challenge than setting up CI/CD for one project. The tools are the same, but the governance, coordination, and self-service patterns transform completely.

Think of it this way: Enterprise DevOps is like city planning — you need roads (golden paths), building codes (governance templates), utilities (shared services), and zoning (project structure). But residents (teams) still choose their own furniture. The goal is autonomy with guardrails, not freedom or control.

The Enterprise Scaling Challenges

• Governance without bureaucracy — How do you enforce security scanning without creating a 3-week approval bottleneck?
• Autonomy with guardrails — Teams need to move fast, but one team's misconfigured pipeline shouldn't expose the whole organization
• Shared infrastructure — Common build templates, agent pools, and artifact feeds that scale without a central team becoming a bottleneck
• Visibility at scale — Leadership needs deployment metrics across 50 teams without micromanaging individual sprints
• Consistent security posture — Every team's pipeline must scan for vulnerabilities, regardless of language or framework

Multi-Team Scaling Patterns

The first decision in enterprise Azure DevOps is project structure — how you organize teams, repos, boards, and pipelines at the organizational level.

Single Project vs. Multi-Project

Area Paths & Iteration Paths for Team Boundaries

In a single-project setup, area paths define team ownership, while iteration paths define sprint cadences. This lets multiple teams share a project while maintaining their own boards and backlogs:

# Area path structure for a multi-team project
# Each team owns a subtree — work items route to their board automatically

MyProduct/
├── Platform Team          # Shared infrastructure team
│   ├── CI/CD              # Pipeline templates, agent pools
│   └── Observability      # Monitoring, alerting
├── Team Alpha             # Feature team A
│   ├── Frontend
│   └── API
├── Team Beta              # Feature team B
│   ├── Mobile
│   └── Backend
└── Team Gamma             # Feature team C
    ├── Data Pipeline
    └── ML Models

# Iteration paths (sprints) — teams can have different cadences
MyProduct/
├── Sprint 24.1            # 2-week sprint (most teams)
├── Sprint 24.2
├── PI 5 / Iteration 1    # SAFe Program Increment (platform team)
└── PI 5 / Iteration 2

Portfolio Management Across Teams

At enterprise scale, work flows from Epics (strategic goals) → Features (deliverables) → User Stories/PBIs (team work) → Tasks (individual effort). Epics and Features typically span multiple teams:

flowchart TD
    E[Epic: Launch Mobile App
Owner: Product Director] --> F1[Feature: User Auth
Team Alpha]
    E --> F2[Feature: Push Notifications
Team Beta]
    E --> F3[Feature: Analytics Dashboard
Team Gamma]
    F1 --> S1[Story: OAuth Login]
    F1 --> S2[Story: Biometric Auth]
    F2 --> S3[Story: iOS Push]
    F2 --> S4[Story: Android Push]
    F3 --> S5[Story: Real-time Metrics]

    style E fill:#132440,color:#fff
    style F1 fill:#16476A,color:#fff
    style F2 fill:#16476A,color:#fff
    style F3 fill:#16476A,color:#fff
    style S1 fill:#3B9797,color:#fff
    style S2 fill:#3B9797,color:#fff
    style S3 fill:#3B9797,color:#fff
    style S4 fill:#3B9797,color:#fff
    style S5 fill:#3B9797,color:#fff
                            

SAFe Implementation with Azure Boards

For organizations using the Scaled Agile Framework (SAFe), Azure Boards provides native support via the Agile or Scrum process templates with portfolio backlogs enabled. Program Increments (PIs) map to iteration paths, and the Delivery Plans extension provides cross-team timeline visualization.

Infrastructure as Code in Pipelines

Infrastructure as Code (IaC) means defining your servers, networks, databases, and cloud services in version-controlled files that pipelines deploy automatically. Instead of clicking through the Azure Portal, you write declarative code that describes the desired state — and your CI/CD pipeline makes it real.

Why IaC Belongs in CI/CD

• Reproducible — Same code = same infrastructure, every time, in any environment
• Reviewable — Infrastructure changes go through pull requests with peer review
• Auditable — Git history shows who changed what infrastructure and when
• Testable — Validate infrastructure before deploying (what-if, plan, dry-run)
• Rollbackable — Revert to previous infrastructure state via git revert

Three IaC Approaches Compared

The Universal IaC Pipeline Pattern

Regardless of which IaC tool you choose, the pipeline pattern is the same:

flowchart LR
    A[Validate
Syntax] --> B[Plan/Preview
Changes]
    B --> C[Manual
Approval]
    C --> D[Apply/Deploy
Infrastructure]
    D --> E[Smoke Test
Verify]

    style A fill:#3B9797,color:#fff
    style B fill:#16476A,color:#fff
    style C fill:#BF092F,color:#fff
    style D fill:#132440,color:#fff
    style E fill:#3B9797,color:#fff
                            

Terraform Pipelines

Terraform is the most popular IaC tool for multi-cloud environments. Its plan → approve → apply workflow maps naturally to Azure DevOps multi-stage pipelines with approval gates.

Remote State in Azure Storage

Terraform's state file tracks what infrastructure exists. In a team setting, this must be stored remotely (never in git) with locking to prevent concurrent modifications:

# Create Azure Storage for Terraform remote state
# Run once per environment during initial setup

# Create resource group for Terraform state
az group create \
  --name rg-terraform-state \
  --location eastus

# Create storage account (globally unique name)
az storage account create \
  --name tfstate${RANDOM}sa \
  --resource-group rg-terraform-state \
  --sku Standard_LRS \
  --encryption-services blob

# Create container for state files
az storage container create \
  --name tfstate \
  --account-name tfstate${RANDOM}sa

# Enable versioning for state file recovery
az storage account blob-service-properties update \
  --account-name tfstate${RANDOM}sa \
  --resource-group rg-terraform-state \
  --enable-versioning true

Complete Terraform Pipeline

# azure-pipelines-terraform.yml
# Complete Terraform pipeline with plan artifact and approval gate
# Pattern: validate → plan (save artifact) → approve → apply (from artifact)

trigger:
  branches:
    include: [main]
  paths:
    include: [infrastructure/]

variables:
  - group: terraform-backend    # Contains storage account details
  - name: tfWorkingDir
    value: '$(System.DefaultWorkingDirectory)/infrastructure'
  - name: serviceConnection
    value: 'azure-terraform-sc'

stages:
  # ─── STAGE 1: VALIDATE & PLAN ─────────────────────────────
  - stage: Plan
    displayName: '📋 Terraform Plan'
    jobs:
      - job: TerraformPlan
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          # Install specific Terraform version for consistency
          - task: TerraformInstaller@1
            displayName: 'Install Terraform 1.7.0'
            inputs:
              terraformVersion: '1.7.0'

          # Initialize with remote backend
          - task: TerraformTaskV4@4
            displayName: 'Terraform Init'
            inputs:
              provider: 'azurerm'
              command: 'init'
              workingDirectory: '$(tfWorkingDir)'
              backendServiceArm: '$(serviceConnection)'
              backendAzureRmResourceGroupName: 'rg-terraform-state'
              backendAzureRmStorageAccountName: '$(TF_STATE_STORAGE)'
              backendAzureRmContainerName: 'tfstate'
              backendAzureRmKey: 'prod.terraform.tfstate'

          # Validate syntax and configuration
          - task: TerraformTaskV4@4
            displayName: 'Terraform Validate'
            inputs:
              provider: 'azurerm'
              command: 'validate'
              workingDirectory: '$(tfWorkingDir)'

          # Generate execution plan and save as file
          - task: TerraformTaskV4@4
            displayName: 'Terraform Plan'
            inputs:
              provider: 'azurerm'
              command: 'plan'
              workingDirectory: '$(tfWorkingDir)'
              environmentServiceNameAzureRM: '$(serviceConnection)'
              commandOptions: '-out=tfplan -detailed-exitcode'

          # Publish plan as pipeline artifact
          - publish: '$(tfWorkingDir)/tfplan'
            artifact: 'terraform-plan'
            displayName: 'Publish plan artifact'

  # ─── STAGE 2: APPLY (with approval gate) ──────────────────
  - stage: Apply
    displayName: '🚀 Terraform Apply'
    dependsOn: Plan
    condition: succeeded()
    jobs:
      - deployment: TerraformApply
        environment: 'production-infrastructure'  # Has approval gate configured
        pool:
          vmImage: 'ubuntu-latest'
        strategy:
          runOnce:
            deploy:
              steps:
                - checkout: self

                - task: TerraformInstaller@1
                  displayName: 'Install Terraform 1.7.0'
                  inputs:
                    terraformVersion: '1.7.0'

                - task: TerraformTaskV4@4
                  displayName: 'Terraform Init'
                  inputs:
                    provider: 'azurerm'
                    command: 'init'
                    workingDirectory: '$(tfWorkingDir)'
                    backendServiceArm: '$(serviceConnection)'
                    backendAzureRmResourceGroupName: 'rg-terraform-state'
                    backendAzureRmStorageAccountName: '$(TF_STATE_STORAGE)'
                    backendAzureRmContainerName: 'tfstate'
                    backendAzureRmKey: 'prod.terraform.tfstate'

                # Download the exact plan from the Plan stage
                - download: current
                  artifact: 'terraform-plan'

                # Apply using the saved plan — no re-planning
                - task: TerraformTaskV4@4
                  displayName: 'Terraform Apply (from plan)'
                  inputs:
                    provider: 'azurerm'
                    command: 'apply'
                    workingDirectory: '$(tfWorkingDir)'
                    environmentServiceNameAzureRM: '$(serviceConnection)'
                    commandOptions: '$(Pipeline.Workspace)/terraform-plan/tfplan'

Bicep & ARM Template Pipelines

Bicep is Microsoft's native IaC language for Azure. It compiles down to ARM templates but with dramatically cleaner syntax. Its biggest advantage over Terraform for Azure-only shops: no state file. Azure Resource Manager itself is the source of truth.

Bicep What-If Preview

The what-if operation shows exactly what will change before deployment — similar to Terraform plan but built into the Azure platform:

# azure-pipelines-bicep.yml
# Bicep deployment with what-if preview and approval gate

trigger:
  branches:
    include: [main]
  paths:
    include: [bicep/]

variables:
  - name: resourceGroup
    value: 'rg-myapp-prod'
  - name: location
    value: 'eastus'
  - name: serviceConnection
    value: 'azure-prod-sc'

stages:
  # ─── STAGE 1: VALIDATE & PREVIEW ──────────────────────────
  - stage: Preview
    displayName: '🔍 What-If Preview'
    jobs:
      - job: BicepPreview
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          # Validate Bicep syntax (catches errors before deployment)
          - task: AzureCLI@2
            displayName: 'Validate Bicep template'
            inputs:
              azureSubscription: '$(serviceConnection)'
              scriptType: 'bash'
              scriptLocation: 'inlineScript'
              inlineScript: |
                az deployment group validate \
                  --resource-group $(resourceGroup) \
                  --template-file bicep/main.bicep \
                  --parameters bicep/parameters.prod.json

          # What-if shows create/modify/delete operations
          - task: AzureCLI@2
            displayName: 'What-If deployment preview'
            inputs:
              azureSubscription: '$(serviceConnection)'
              scriptType: 'bash'
              inlineScript: |
                echo "## Infrastructure Changes Preview" >> $(Build.SourcesDirectory)/whatif-output.md
                echo '```' >> $(Build.SourcesDirectory)/whatif-output.md

                az deployment group what-if \
                  --resource-group $(resourceGroup) \
                  --template-file bicep/main.bicep \
                  --parameters bicep/parameters.prod.json \
                  --result-format FullResourcePayloads \
                  2>&1 | tee -a $(Build.SourcesDirectory)/whatif-output.md

                echo '```' >> $(Build.SourcesDirectory)/whatif-output.md

          - publish: '$(Build.SourcesDirectory)/whatif-output.md'
            artifact: 'whatif-results'

  # ─── STAGE 2: DEPLOY (with approval) ──────────────────────
  - stage: Deploy
    displayName: '🚀 Deploy Infrastructure'
    dependsOn: Preview
    jobs:
      - deployment: BicepDeploy
        environment: 'production-infrastructure'
        pool:
          vmImage: 'ubuntu-latest'
        strategy:
          runOnce:
            deploy:
              steps:
                - checkout: self

                - task: AzureCLI@2
                  displayName: 'Deploy Bicep template'
                  inputs:
                    azureSubscription: '$(serviceConnection)'
                    scriptType: 'bash'
                    inlineScript: |
                      az deployment group create \
                        --resource-group $(resourceGroup) \
                        --template-file bicep/main.bicep \
                        --parameters bicep/parameters.prod.json \
                        --name "deploy-$(Build.BuildId)"

Container & AKS Deployments

Containers are the deployment unit for modern cloud-native applications. Azure Pipelines provides first-class support for building container images, pushing them to Azure Container Registry (ACR), and deploying to Azure Kubernetes Service (AKS).

Complete Container Pipeline: Build → Push → Deploy

# azure-pipelines-aks.yml
# Full container lifecycle: build image → push to ACR → deploy to AKS

trigger:
  branches:
    include: [main]

variables:
  - name: dockerRegistryServiceConnection
    value: 'acr-connection'
  - name: imageRepository
    value: 'myapp/api'
  - name: containerRegistry
    value: 'mycompanyacr.azurecr.io'
  - name: dockerfilePath
    value: '$(Build.SourcesDirectory)/Dockerfile'
  - name: tag
    value: '$(Build.BuildId)'
  - name: k8sNamespace
    value: 'production'

stages:
  # ─── STAGE 1: BUILD & PUSH CONTAINER ──────────────────────
  - stage: Build
    displayName: '🐳 Build & Push'
    jobs:
      - job: BuildContainer
        pool:
          vmImage: 'ubuntu-latest'
        steps:
          # Build and push to ACR in one step
          - task: Docker@2
            displayName: 'Build and push image'
            inputs:
              containerRegistry: '$(dockerRegistryServiceConnection)'
              repository: '$(imageRepository)'
              command: 'buildAndPush'
              Dockerfile: '$(dockerfilePath)'
              tags: |
                $(tag)
                latest

          # Scan the image for vulnerabilities before deploying
          - script: |
              # Trivy scan against the just-pushed image
              trivy image --exit-code 1 --severity CRITICAL \
                $(containerRegistry)/$(imageRepository):$(tag)
            displayName: 'Scan container image'

          # Publish Kubernetes manifests for the deploy stage
          - publish: '$(Build.SourcesDirectory)/k8s'
            artifact: 'manifests'

  # ─── STAGE 2: DEPLOY TO AKS ───────────────────────────────
  - stage: Deploy
    displayName: '☸️ Deploy to AKS'
    dependsOn: Build
    jobs:
      - deployment: DeployToAKS
        environment: 'production-aks.$(k8sNamespace)'
        pool:
          vmImage: 'ubuntu-latest'
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: 'manifests'

                # Deploy using Kubernetes manifest task
                - task: KubernetesManifest@1
                  displayName: 'Deploy to AKS'
                  inputs:
                    action: 'deploy'
                    connectionType: 'azureResourceManager'
                    azureSubscriptionConnection: 'azure-prod-sc'
                    azureResourceGroup: 'rg-aks-prod'
                    kubernetesCluster: 'aks-prod-cluster'
                    namespace: '$(k8sNamespace)'
                    manifests: |
                      $(Pipeline.Workspace)/manifests/deployment.yml
                      $(Pipeline.Workspace)/manifests/service.yml
                    containers: |
                      $(containerRegistry)/$(imageRepository):$(tag)

                # Verify deployment health
                - task: Kubernetes@1
                  displayName: 'Check rollout status'
                  inputs:
                    connectionType: 'Azure Resource Manager'
                    azureSubscriptionEndpoint: 'azure-prod-sc'
                    azureResourceGroup: 'rg-aks-prod'
                    kubernetesCluster: 'aks-prod-cluster'
                    namespace: '$(k8sNamespace)'
                    command: 'rollout'
                    arguments: 'status deployment/myapp-api --timeout=300s'

flowchart LR
    A[Source Code
+ Dockerfile] --> B[Docker Build
on Agent]
    B --> C[Push to
ACR]
    C --> D[Security
Scan]
    D --> E[Deploy to
AKS]
    E --> F[Health
Check]

    style A fill:#132440,color:#fff
    style C fill:#16476A,color:#fff
    style D fill:#BF092F,color:#fff
    style E fill:#3B9797,color:#fff
                            

Platform Engineering

Platform engineering is the discipline of building internal developer platforms — self-service systems that let development teams deploy, monitor, and manage applications without needing deep infrastructure expertise or waiting for a central ops team.

Golden Paths

Golden paths (also called "paved roads") are opinionated, pre-built workflows for common patterns. They encode best practices into templates that teams can adopt with minimal effort:

• New microservice → Template repo with Dockerfile, pipeline, Helm chart, monitoring dashboards
• New API → Scaffold with authentication, rate limiting, OpenAPI spec, integration tests
• New database → Provisioned via IaC template with backups, monitoring, connection string in Key Vault
• New team onboarding → Project created with RBAC, feeds, environments, and service connections pre-configured

Template Repositories as Platform Building Blocks

# Template repository structure for a platform team
# Teams fork or reference these to bootstrap new services

pipeline-templates/
├── stages/
│   ├── build-dotnet.yml         # .NET build + test + publish
│   ├── build-node.yml           # Node.js build + lint + test
│   ├── build-python.yml         # Python build + pytest + coverage
│   ├── security-scan.yml        # SAST + SCA + container scan
│   ├── deploy-aks.yml           # AKS deployment with health checks
│   └── deploy-appservice.yml    # App Service deployment
├── jobs/
│   ├── docker-build-push.yml    # Container build + ACR push
│   └── terraform-apply.yml      # Terraform plan/apply pattern
├── steps/
│   ├── sonarqube-scan.yml       # Code quality analysis
│   ├── notify-teams.yml         # MS Teams notification
│   └── tag-release.yml          # Git tagging for releases
└── variables/
    ├── global.yml               # Organization-wide variables
    └── environments.yml         # Environment-specific configs

# Teams consume templates like this:
# resources:
#   repositories:
#     - repository: templates
#       type: git
#       name: SharedProject/pipeline-templates
#
# stages:
#   - template: stages/build-dotnet.yml@templates
#   - template: stages/security-scan.yml@templates
#   - template: stages/deploy-aks.yml@templates

Self-Service Developer Portal

The ultimate platform engineering goal: developers go to a portal, click "New Microservice," fill in a name and team, and get a fully configured repository with CI/CD, monitoring, and deployment pipeline — all within minutes, not weeks.

AI-Powered Azure DevOps (2026)

The integration of AI into DevOps workflows — sometimes called AIOps or AI-assisted engineering — is transforming how teams interact with Azure DevOps. In 2026, the most impactful integration pattern uses MCP (Model Context Protocol) to let AI agents interact directly with Azure DevOps services.

Azure Boards MCP Server

The Azure Boards MCP server exposes work item management to AI agents. Instead of navigating the web UI or writing REST API calls, you describe what you want in natural language:

// Example: AI agent creating a work item via MCP
// The agent translates natural language into structured API calls

// User prompt: "Create a bug for the login page timeout issue
//               affecting users in the EU region"

// MCP server receives structured request:
{
  "tool": "azure_boards",
  "action": "create_work_item",
  "parameters": {
    "project": "MyApp",
    "type": "Bug",
    "title": "Login page timeout for EU region users",
    "description": "Users in the EU region experience timeouts...",
    "area_path": "MyApp/Team Alpha/Frontend",
    "iteration_path": "MyApp/Sprint 24.3",
    "priority": 2,
    "tags": ["login", "performance", "eu-region"]
  }
}

// AI can also query: "What bugs are blocking the current sprint?"
{
  "tool": "azure_boards",
  "action": "query_work_items",
  "parameters": {
    "wiql": "SELECT [Id], [Title], [State] FROM WorkItems WHERE [Work Item Type] = 'Bug' AND [State] = 'Active' AND [Tags] CONTAINS 'blocking' AND [Iteration Path] UNDER 'MyApp/Sprint 24.3'"
  }
}

AI-Assisted Workflows

• Sprint planning — AI analyzes velocity history, suggests story point estimates, flags over-committed sprints
• PR summaries — Copilot generates human-readable descriptions of code changes for reviewers
• Pipeline generation — Describe your app ("Node.js API with PostgreSQL, deploy to AKS") and get a complete pipeline YAML
• Test generation — AI analyzes code changes and generates integration tests for new endpoints
• Incident correlation — AI connects deployment events to monitoring alerts and suggests root causes

flowchart LR
    A[Developer
Natural Language] --> B[AI Agent
LLM]
    B --> C[MCP Server
Protocol Layer]
    C --> D[Azure Boards
Work Items]
    C --> E[Azure Repos
Code & PRs]
    C --> F[Azure Pipelines
CI/CD]
    C --> G[Azure Test Plans
Results]

    style A fill:#132440,color:#fff
    style B fill:#BF092F,color:#fff
    style C fill:#16476A,color:#fff
    style D fill:#3B9797,color:#fff
    style E fill:#3B9797,color:#fff
    style F fill:#3B9797,color:#fff
    style G fill:#3B9797,color:#fff
                            

Migration Strategies

Migrating to Azure DevOps from other platforms is never a 1:1 translation — it's an opportunity to modernize. Don't just convert Jenkinsfiles line by line; redesign for Azure Pipelines' native capabilities like YAML templates, environments, and deployment jobs.

Migration Paths Overview

Jenkins → Azure Pipelines: Side-by-Side

# ┌─────────────────────────────────────────────────────────────┐
# │ JENKINS (Jenkinsfile - Declarative)                         │
# └─────────────────────────────────────────────────────────────┘
# pipeline {
#     agent { docker { image 'node:18' } }
#     environment {
#         DB_CREDS = credentials('database-credentials')
#     }
#     stages {
#         stage('Install') {
#             steps { sh 'npm ci' }
#         }
#         stage('Test') {
#             steps { sh 'npm test' }
#         }
#         stage('Deploy') {
#             when { branch 'main' }
#             steps { sh './deploy.sh' }
#         }
#     }
#     post {
#         failure { slackSend '#builds', 'Build failed!' }
#     }
# }

# ┌─────────────────────────────────────────────────────────────┐
# │ AZURE PIPELINES (azure-pipelines.yml)                       │
# └─────────────────────────────────────────────────────────────┘
trigger:
  branches:
    include: [main]

pool:
  vmImage: 'ubuntu-latest'

# Container equivalent of Jenkins docker agent
container: node:18

variables:
  - group: database-credentials   # Linked to Key Vault

stages:
  - stage: Build
    jobs:
      - job: BuildAndTest
        steps:
          - script: npm ci
            displayName: 'Install dependencies'

          - script: npm test
            displayName: 'Run tests'

  - stage: Deploy
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: DeployProd
        environment: 'production'
        strategy:
          runOnce:
            deploy:
              steps:
                - script: ./deploy.sh
                  displayName: 'Deploy application'

# Post-failure notification (use service hook or Teams webhook)
# Configure in Project Settings → Service hooks → Microsoft Teams

Observability & SRE Integration

Enterprise DevOps doesn't end at deployment — it extends into observability: understanding how your systems behave in production and using that data to make deployment decisions automatically.

Deployment Gates Using Azure Monitor

Deployment gates automatically query external systems and block or proceed based on results. Combine these with Azure Monitor to create intelligent release validation:

• Pre-deployment gate — Check no active incidents in Azure Monitor before deploying
• Post-deployment gate — Wait 10 minutes after deployment, then check error rates in Application Insights
• SLO validation — Verify that the new deployment doesn't breach SLO thresholds (p99 latency, error budget)

# Deployment gate: Query Azure Monitor for error rate after deployment
# If error rate exceeds threshold, the gate fails and blocks progression

# In the environment's approval & checks settings:
# Add check → "Invoke Azure Monitor alerts"
# Or use REST API gate with a custom KQL query:

# Custom gate — query Application Insights via REST
- stage: ValidateDeployment
  jobs:
    - job: HealthCheck
      pool: server  # Agentless job (runs on Azure DevOps server)
      steps:
        - task: InvokeRestAPI@1
          displayName: 'Check error rate in App Insights'
          inputs:
            connectionType: 'connectedServiceName'
            serviceConnection: 'azure-monitor-sc'
            method: 'POST'
            urlSuffix: '/v1/apps/$(APP_INSIGHTS_ID)/query'
            body: |
              {
                "query": "requests | where timestamp > ago(10m) | summarize errorRate = countif(success == false) * 100.0 / count() | project errorRate"
              }
            waitForCompletion: 'true'
            successCriteria: 'lt(root[''tables''][0][''rows''][0][0], 5)'  # Error rate < 5%

SLI/SLO Tracking Linked to Deployments

Site Reliability Engineering (SRE) practices connect deployment events to service health. Azure DevOps deployment markers in Application Insights let you correlate degradation with specific releases:

• SLI (Service Level Indicator) — Measurable metric (e.g., p99 latency = 200ms)
• SLO (Service Level Objective) — Target for the SLI (e.g., p99 latency < 300ms, 99.5% of the time)
• Error budget — How much SLO violation you can tolerate before freezing deployments

Capstone Project: Full Enterprise Platform

This capstone ties together all 11 modules of the Azure DevOps Bootcamp. You'll design a complete DevOps platform for a realistic enterprise scenario.

Exercises