{"id":3557,"date":"2025-12-09T10:34:22","date_gmt":"2025-12-09T18:34:22","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/azure-sdk\/?p=3557"},"modified":"2025-12-09T10:34:22","modified_gmt":"2025-12-09T18:34:22","slug":"azure-developer-cli-azd-blue-green-aca-deployment","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/azure-sdk\/azure-developer-cli-azd-blue-green-aca-deployment\/","title":{"rendered":"Blue-green deployment in Azure Container Apps using Azure Developer CLI"},"content":{"rendered":"

Blue-green deployment in Azure Container Apps using Azure Developer CLI<\/h1>\n

If you follow the Azure Developer CLI blog posts<\/a>, you already know that Azure Container Apps (ACA) support in Azure Developer CLI (azd) is GA<\/strong>. We want azd<\/code> to be production-ready\u2014you should be able to plug in the Bicep code your team uses and just run azd up<\/code>. While getting the support GA-ready, one of the improvements we made was revision-based deployment support<\/a>, which means azd<\/code> can now handle advanced rollout patterns like blue-green deployment<\/strong>.<\/p>\n

Blue-green deployment brings back fond memories. One of the first Jenkins blog posts I worked on was about blue-green deployment for Azure Kubernetes Service (AKS). I remember how much effort the engineer put into creating that quickstart\u2014and how much longer I spent trying to understand what was going on. It’s great to see something that complex become almost trivial now.<\/p>\n

For this demo, I asked Copilot to help generate a Python app to illustrate the workflow. No code changes needed\u2014you can clearly see whether you’re using the blue or green revision. The Bicep is based on Blue-green deployment in ACA<\/a> and the workflow on the containerapps-blue-green sample<\/a>.<\/p>\n

To run locally<\/h2>\n

Note:<\/strong> The commit IDs in this demo (fb699ef<\/code>, c6f1515<\/code>) are just examples. You can use any identifiers you want\u2014like blue-v1<\/code>, 12345<\/code>, or actual git commit hashes (as shown in the CI\/CD workflow azure-dev.yml<\/code>).<\/p><\/blockquote>\n

    \n
  1. In an empty folder, run azd init -t puichan\/aca-blue-green<\/code>.<\/li>\n
  2. To deploy BLUE:\n
    azd env set BLUE_COMMIT_ID fb699ef\r\nazd env set LATEST_COMMIT_ID fb699ef<\/code><\/pre>\n<\/li>\n
  3. Run azd up<\/code>\n
    Note:<\/strong> On first deployment, only the blue revision is created since GREEN_COMMIT_ID<\/code> isn’t set. The Bicep logic (!empty(blueCommitId) && !empty(greenCommitId)<\/code>) skips traffic splitting until both revisions exist.<\/p><\/blockquote>\n
    \"Blue<\/li>\n
  4. To deploy GREEN, but keep traffic on BLUE:\n
    \/\/ Create green revision\r\nazd env set GREEN_COMMIT_ID c6f1515\r\nazd env set LATEST_COMMIT_ID c6f1515\r\n\r\n\/\/ keep traffic on BLUE\r\nazd env set PRODUCTION_LABEL blue<\/code><\/pre>\n
    Note:<\/strong> LATEST_COMMIT_ID<\/code> tells Bicep which revision to deploy. When you change it, a new revision is created. When you keep it the same and only change PRODUCTION_LABEL<\/code> (as shown later), traffic just switches between existing revisions.<\/p><\/blockquote>\n
    And then run azd deploy<\/code><\/p>\n
    If you click the app endpoint, you still see the blue deployment. You see the blue deployment because PRODUCTION_LABEL<\/code> is set to “blue”\u2014traffic stays on blue. You can see the traffic logic in web.bicep<\/code><\/a>:<\/p>\n
          traffic: !empty(blueCommitId) && !empty(greenCommitId) ? [\r\n      {\r\n        revisionName: '${containerAppName}--${blueCommitId}'\r\n        weight: productionLabel == 'blue' ? 100 : 0\r\n        label: 'blue'\r\n      }\r\n      {\r\n        revisionName: '${containerAppName}--${greenCommitId}'\r\n        weight: productionLabel == 'green' ? 100 : 0\r\n        label: 'green'\r\n      }<\/code><\/pre>\n
    To test, run this command to get all three fully qualified domain names (FQDNs):<\/p>\n
    $uri = azd env get-value \"SERVICE_WEB_URI\"; $domain = ([System.Uri]$uri).Host.Split('.', 2)[1]; Write-Host \"Production FQDN: $uri\"; Write-Host \"Blue label FQDN: https:\/\/web---blue.$domain\"; Write-Host \"Green label FQDN: https:\/\/web---green.$domain\"<\/code><\/pre>\n
    Click the links in the output to see the production, blue and green label FQDN.<\/p>\n
    Production FQDN: https:\/\/web.purplerock-d77264b4.westus.azurecontainerapps.io\r\nBlue label FQDN: https:\/\/web---blue.purplerock-d77264b4.westus.azurecontainerapps.io\r\nGreen label FQDN: https:\/\/web---green.purplerock-d77264b4.westus.azurecontainerapps.io<\/code><\/pre>\n
    You can also run az containerapp ingress traffic show --name web --resource-group <your-resource-group> -o table<\/code>. Output:<\/p>\n
    Label    RevisionName    Weight\r\n-------  --------------  --------\r\nblue     web--fb699ef    100\r\ngreen    web--c6f1515    0<\/code><\/pre>\n<\/li>\n
  5. To send production traffic to the green revision, set PRODUCTION_LABEL<\/code> to “green” and then run azd deploy<\/code> again:\n
    azd env set PRODUCTION_LABEL green\r\nazd deploy<\/code><\/pre>\n
    Click the endpoint\u2014ta-da, green!<\/p>\n
    \"Green<\/p>\n
    Again, you can check:<\/p>\n
    az containerapp ingress traffic show --name web --resource-group <your-resource-group> -o table<\/code><\/pre>\n<\/li>\n
  6. To roll back to BLUE:\n
    azd env set PRODUCTION_LABEL blue\r\nazd deploy<\/code><\/pre>\n<\/li>\n<\/ol>\n
    CI\/CD with GitHub Actions<\/h2>\n
    To set up the GitHub workflow, the sample repo<\/a> contains a customized azure-dev.yml<\/code>. Run the azd pipeline config<\/code> command and you’re done.<\/p>\n
    Things to know<\/h2>\n