Managing Environments in CI/CD Pipelines

Environment isolation strategies

The level of isolation between environments trades cost for safety. Three common patterns:

• Shared subscription, separate resource groups. Dev, staging, and prod all exist in the same Azure subscription but in separate resource groups with different IAM permissions. Cheapest option, lowest isolation. A misconfigured subscription-level policy or an admin mistake can affect all environments. Acceptable for small teams with low-risk applications.
• Separate subscriptions per environment. Dev, staging, and prod each get their own Azure subscription. Strong isolation boundary — subscription-level quotas, policies, and billing are completely independent. The correct approach for production workloads. Use Azure Management Groups to apply governance policies across all subscriptions consistently.
• Separate Azure AD tenants. Extreme isolation for compliance-heavy scenarios where even admin access must be separated. Rarely needed, significant management overhead. Typically reserved for scenarios where regulatory requirements mandate complete tenant-level separation.

Variable groups per environment

Environment-specific configuration (connection strings, API endpoints, feature flags, resource names) should come from variable groups, not from hardcoded pipeline YAML. Each environment gets its own variable group containing values specific to that environment:

# Pipeline references environment-specific variable groups
stages:
  - stage: DeployDev
    variables:
      - group: vg-myapp-dev    # Contains: APP_URL, DB_CONNECTION_STRING, etc.
    jobs:
      - deployment: DeployApp
        environment: env-dev
        strategy:
          runOnce:
            deploy:
              steps:
                - script: echo "Deploying to $(APP_URL)"

  - stage: DeployStaging
    dependsOn: DeployDev
    variables:
      - group: vg-myapp-staging
    jobs:
      - deployment: DeployApp
        environment: env-staging
        strategy:
          runOnce:
            deploy:
              steps:
                - script: echo "Deploying to $(APP_URL)"

  - stage: DeployProd
    dependsOn: DeployStaging
    variables:
      - group: vg-myapp-prod
    jobs:
      - deployment: DeployApp
        environment: env-prod
        strategy:
          runOnce:
            deploy:
              steps:
                - script: echo "Deploying to $(APP_URL)"

The same pipeline YAML deploys to all three environments. Only the variable group changes per stage. This pattern ensures you are deploying the same artifact with environment-appropriate configuration, not different code per environment.

Azure DevOps Environments with approvals

Azure DevOps Environments are the mechanism for approval gates. Create an environment for each deployment target, then configure checks on that environment:

In Azure DevOps, navigate to Pipelines > Environments, create an environment named env-staging and another named env-prod. On env-prod, add an Approvals check requiring sign-off from specific users or groups before any pipeline can deploy to it.

When the pipeline reaches the stage that deploys to env-prod, it pauses and notifies the designated approvers. The deployment does not proceed until someone approves it. This creates a human gate between staging validation and production deployment.

Service connections per environment

Each environment should use a separate Azure service connection configured with a separate service principal or managed identity. The prod service connection should have minimal permissions — only what is needed to deploy, nothing else.

stages:
  - stage: DeployDev
    jobs:
      - deployment: DeployApp
        environment: env-dev
        pool:
          vmImage: ubuntu-latest
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: 'sc-myapp-dev'    # Dev service connection
                    appName: 'app-myapp-dev'
                    package: '$(Pipeline.Workspace)/drop/*.zip'

  - stage: DeployProd
    dependsOn: DeployStaging
    jobs:
      - deployment: DeployApp
        environment: env-prod
        pool:
          vmImage: ubuntu-latest
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: 'sc-myapp-prod'   # Separate prod service connection
                    appName: 'app-myapp-prod'
                    package: '$(Pipeline.Workspace)/drop/*.zip'

Building once, deploying everywhere

A critical principle: build the application artifact once in a build stage, publish it, and then deploy that same artifact to dev, staging, and production in sequence. Never rebuild the artifact per environment. If you rebuild, you risk subtle differences introduced by dependency version resolution or environment-specific build settings. The artifact that passed staging tests must be byte-for-byte identical to what goes to production.

stages:
  - stage: Build
    jobs:
      - job: BuildApp
        pool:
          vmImage: ubuntu-latest
        steps:
          - task: DotNetCoreCLI@2
            inputs:
              command: publish
              publishWebProjects: true
              arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)'
          - publish: $(Build.ArtifactStagingDirectory)
            artifact: drop

  - stage: DeployDev
    dependsOn: Build
    jobs:
      - deployment: Deploy
        environment: env-dev
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: drop
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: 'sc-myapp-dev'
                    appName: 'app-myapp-dev'
                    package: '$(Pipeline.Workspace)/drop/**/*.zip'