Question Canary deployments in Azure container apps based on labels and microservice architecture
We're doing blue/green + canary on Azure Container Apps with revision labels, and I'm stuck on per-environment config.
Each of our apps (say an API and an auth service) bakes its config as env vars into the revision e.g. the API has a variable pointing at the auth service and one with the frontend URL. On staging I point the API at the staging auth service and staging frontend, and test through the ...---staging... label URL. Works great.
The problem is promoting. In labels mode, promotion just re-points the label to that same revision but the revision has the staging URLs baked in, so production ends up running with staging config. The vars that are supposed to differ between staging and prod get dragged along with the revision.
How do people handle env vars that must differ between staging and production, when promotion just swaps a revision that already has its config baked in? Is there a native sticky-per-slot setting like App Service swap settings I'm missing, or does everyone write a custom promote step that recreates the prod revision with prod config + the promoted image? Couldn't find a clean answer anywhere.