Hands-on with Standardized Change Management for Azure Deployments

Organizations operating on Azure frequently encounter a critical operational risk: ad-hoc, undocumented changes that silently introduce configuration drift, service outages, and failed rollbacks. This tutorial addresses that gap using Python 3.10 runbooks running on a self-hosted Azure DevOps agent.

The core question

How do you make every production change to an Azure resource requested, approved, executed, validated, and documented through one auditable pipeline, instead of an engineer running ad-hoc CLI or Portal commands that nobody tracked?

An undocumented change is a change nobody can trust. When a production VMSS gets scaled by hand from the CLI, there's no record of who did it, why, what the prior state was, or whether anyone reviewed it first. The first sign of trouble is usually an outage, at which point rollback fails too, because the prior state was never captured.

This use case replaces that with a single pipeline that intake, approves, executes, validates, and documents every change end to end.

Architecture overview

The solution integrates four Azure and Atlassian services. All automation logic is in Python 3.10 running on a self-hosted Azure DevOps agent pool.

Use this approach when

• Production changes currently happen by hand. Engineers run CLI or Portal commands directly against live resources, with nothing recording who changed what.
• You've had a failed rollback. A rollback that fails because the prior state was never captured is a sign this pipeline is overdue.
• There's no approval gate today. Anyone with access can change production at any time, with no second set of eyes.
• Audit or change-management documentation is expected of you. A Work-Item-to-pipeline-to-change-log trail is what an auditor or ITSM process wants to see.
• You already run Azure DevOps and Azure Automation, or can. This pattern is built on them directly, not a new platform.
• Confluence (or a similar wiki) is where your team expects change history to live, but nobody reliably updates it today.

When this is not the right fit

• You don't have a self-hosted Azure DevOps agent pool, or can't stand one up the pipeline depends on it.
• Your team doesn't use Azure DevOps Boards for work tracking. The approval gate here is built on a custom Work Item type; porting this to Jira or another tracker is a different build.
• You need this for resource types beyond VMSS without adapting the runbook. The example runbook in this lab is written specifically for VMSS capacity changes; other resource types need their own runbook logic.
• You're not using Confluence Cloud. The documentation step uses the Confluence REST API directly and Basic Auth with a personal API token; a different wiki needs a different integration.

Accounts and access

• An Azure subscription with rights to create resource groups, VMSS, an Automation Account, a Log Analytics workspace, Monitor alerts, and a Key Vault
• An Azure DevOps organization, with permission to customize the process (add a Work Item type, fields, and states) and create pipelines, environments, and service connections
• A Confluence Cloud site, with permission to create a space and a page
• An Atlassian account email for API token generation

Tools and runtime

Access tokens to generate

• An Azure DevOps Personal Access Token (PAT) with full access scope, used by the pipeline for az boards calls
• A Confluence API token, generated from your Atlassian account, used for Basic Auth against the Confluence REST API
• Both tokens are stored in Azure Key Vault rather than in pipeline variables directly

Knowledge assumed

• Comfort with Azure CLI and the Azure portal
• Basic Python
• Azure DevOps Boards and YAML pipelines
• Basic KQL for the audit workbook queries