Howto implement an Aspire/AZD github workflow for deployment to test and production

[Lindsay-Mathieson]

Currently have a modified azd pipeline generated github workflow for deploying to our Azure test env, works the best.

Locally I have 2 environments set up via azd env new (aspire-test, aspire-prod) and can push out to the respective environments via azd deploy

Want to update my workflow it for deployment to production as well and for the life of me cannot figure out how to do so, it depends on the AZD_INITIAL_ENVIRONMENT_CONFIG setup by azd pipeline config and that only works with the env selected when pipeline config was last run.

[vhvb1989]

Hi @Lindsay-Mathieson
We are about to merge #5143 which will get rid of AZD_INITIAL_ENVIRONMENT_CONFIG.
Each parameter from your AppHost will be directly mapped to either a Github CI variable or secret.

AZD currently only supports one GitHub CI environment. We initially designed like this b/c azd pipeline config creates a private repo by default and CI environments are only free for public repos. So this functionality to support CI enviroments mapped to AZD-environments is still ToBeImplemented.

A current (ugly) alternative is to map one AZD-env to one repo and another AZD-env to other repo. You can do this by using a different git remote. So when you call azd pipeline config, you can pass azd pipeline config --remote-name foo and azd would add the remote foo linked to a new github repo.
This is a complicated alternative but it can help you to at least set up on repo for Dev and another for PROD. Then you would typically run git push Dev and only git push Prod when ready to send your changes to PROD.

In the future, we will add support for GH CI environments, for sure. We are just not yet there.

[Lindsay-Mathieson]

So when you call azd pipeline config, you can pass azd pipeline config --remote-name foo and azd would add the remote foo linked to a new github repo.

That did the trick! I actually wrote a long reply to this, but it seems to have vanished :( But have implemented it. Rather than pushing src to Production repo, I am invoking the src workflow from Production with inherit secrets, a little tweaking and it works the best. Now can auto/manual deploy testing and manually deploy Prod via workflows.

Thank you so much!