Microsoft Azure for DevOps

Microsoft Azure for DevOps #

Azure is a strong fit for organizations that need enterprise identity integration, policy-driven governance, and flexible platform choices from PaaS to Kubernetes.

Overview #

Typical Azure DevOps stacks combine:

  • Identity and access with Microsoft Entra ID and Azure RBAC.
  • Governance with management groups, policies, and landing zones.
  • Delivery automation with Azure DevOps Pipelines or GitHub Actions.
  • Operations with Azure Monitor, Log Analytics, and Application Insights.

When to use Azure / decision criteria #

Choose Azure when you need:

  • Tight integration with Microsoft enterprise identity and tooling.
  • Strong governance with policy and management-group hierarchy.
  • Managed application platforms including AKS and App Service.

Tradeoffs to plan for:

  • Subscription and policy hierarchy must be designed early.
  • Networking and peering complexity grows quickly without standards.
  • RBAC scope inheritance can become hard to reason about.

Architecture patterns #

1) Landing zone by management group #

  • Separate production and non-production subscriptions.
  • Apply baseline policy initiatives at management group level.
  • Centralize shared networking, logging, and security tooling.

2) AKS platform pattern #

  • Separate clusters by environment and risk profile.
  • Integrate workload identities for pod/service authentication.
  • Standardize ingress, policy admission, and observability add-ons.

3) App Service pattern #

  • Use deployment slots for safe rollouts.
  • Automate infra + app deployment in single pipeline.
  • Use managed identity for service-to-service access.

Security and cost guardrails #

Security baseline #

  • Enforce MFA and conditional access for privileged users.
  • Use managed identities instead of stored secrets when possible.
  • Keep secrets and certificates in Azure Key Vault.
  • Enable centralized audit and platform logging.

Cost baseline #

  • Tag resources for ownership and cost center tracking.
  • Set budgets and alerts at subscription/resource group levels.
  • Use autoscale and right-sizing recommendations.
  • Regularly review idle resources and reserved capacity options.

Implementation examples #

Example Bicep policy bootstrap snippet # 

param location string = resourceGroup().location

resource logAnalytics "Microsoft.OperationalInsights/workspaces@2022-10-01" = {
  name: "law-platform-${uniqueString(resourceGroup().id)}"
  location: location
  properties: {
    sku: { name: "PerGB2018" }
    retentionInDays: 30
  }
}

resource storageHttpsOnly "Microsoft.Authorization/policyAssignments@2022-06-01" = {
  name: "require-https-storage"
  properties: {
    policyDefinitionId: "/providers/Microsoft.Authorization/policyDefinitions/2a1a9cdf-e04d-429a-8416-3bfb72a1b26f"
    displayName: "Require secure transfer for Storage Accounts"
  }
}

Example CI/CD flow #

  1. Pull request validation with unit tests and security checks.
  2. Build and publish artifact/container.
  3. Deploy to test environment and run smoke tests.
  4. Promote to production using approvals and rollout strategy.
  5. Track deployment health with monitor alerts and dashboards.

Example Terraform baseline #

  • Subscription-level role assignments and policy sets.
  • Network baseline modules (hub/spoke or equivalent).
  • Log Analytics workspace and standard alert rules.

Migration/adoption path #

  1. Create management groups and baseline policy initiatives first.
  2. Roll out hub-and-spoke networking and central observability before app migrations.
  3. Move CI/CD to workload identities and Key Vault-backed secret retrieval.
  4. Migrate low-risk applications to AKS/App Service, then expand to regulated workloads.
  5. Add policy exemptions with expiry dates to prevent permanent governance drift.

Pitfalls / anti-patterns #

  • Flat subscription model without governance boundaries.
  • Secrets embedded in pipeline variables without rotation.
  • Manual environment drift from click-ops changes.
  • Missing ownership tags and spending controls.

References #