Best Practices for Dev-to-Prod Promotion with Azure Developer CLI

[puicchan]

🤔 The Question

What's the recommended approach for promoting applications from development to production using Azure Developer CLI? We've been exploring patterns for "build once, deploy everywhere" workflows and would love community input on best practices.

🔍 Current Challenge

Many teams need to:

1. Deploy and validate applications in development environments
2. Promote the same build artifacts to production
3. Handle environment-specific infrastructure (dev: public access, prod: private networking)
4. Maintain consistency while ensuring production security

💡 Our Current Approach

We've been experimenting with enhancing the azd pipeline config generated workflow to support dev-to-prod promotion:

Infrastructure: Environment-Aware with envType

Using conditional Bicep deployment based on environment type:

// Deploy VNet only for production
module network './network.bicep' = if (envType == 'prod') {
  name: 'networkDeployment'
  // ...
}

// Storage with environment-specific access
publicNetworkAccess: envType == 'prod' ? 'Disabled' : 'Enabled'

Pipeline: Package Preservation

Modified the GitHub Actions workflow to preserve build artifacts:

- name: Package Application
  run: |
    azd package app --output-path ./dist/app-package.zip
    cp ./dist/app-package.zip ./app-package-backup.zip

- name: Deploy to Development  
  run: azd deploy app --from-package ./dist/app-package.zip --no-prompt

- name: Promote to Production
  run: |
    PROD_ENV_NAME="${AZURE_ENV_NAME%-dev}-prod"
    export AZURE_ENV_NAME="$PROD_ENV_NAME"
    export AZURE_ENV_TYPE="prod"
    azd deploy app --from-package ./app-package-backup.zip --no-prompt

Environment Management

# Development
azd up  # (envType defaults to 'dev')

# Production  
azd env new myproj-prod
azd env set AZURE_ENV_TYPE prod
azd up

🎯 Key Questions for Discussion

1. Is this the intended pattern for azd? Should customers be enhancing azd pipeline config output, or is there a better built-in approach?

2. Environment-specific infrastructure: Is using envType parameters in Bicep the recommended way to handle dev/prod infrastructure differences?

3. Package preservation: The azd deploy --from-package command consumes the package file. Is copying the package the right approach, or is there a better way to reuse build artifacts?

4. Environment naming: Should there be conventions or built-in support for environment naming patterns (e.g., myapp-dev → myapp-prod)?

5. Multi-environment workflows: Should there be a native multi-environment promotion support in azd, something like azd promote --from-env dev --to-env prod?

📝 Example Implementation

We've created a working example that demonstrates this pattern:

• Template: azd init -t https://github.com/puicchan/azd-dev-prod-appservice-storage
• Features environment-aware Bicep templates and enhanced CI/CD pipeline
• Shows practical dev-to-prod promotion with the same build artifacts

🤝 Community Input Needed

How do you handle dev-to-prod promotion with azd?

• Do you use similar environment-aware infrastructure patterns?
• How do you manage build artifacts across environments?
• What challenges have you encountered?
• What would make this easier?

We'd love to hear from the community about the best path forward for these scenarios!

---

Looking forward to the discussion and learning from the community's experiences! 🙏