Open pamelafox opened 8 months ago
Related #3272
Part of me wonders if we should try to model this as conditions on steps in a workflow (now that we are moving down that path with how up
works) instead of having conditions on the actual services.
Part of me wonders if we should try to model this as conditions on steps in a workflow (now that we are moving down that path with how
up
works) instead of having conditions on the actual services.
If represented as a workflow user could manually call azd deploy foo
for each interested service in a workflow.
My company needs this as well. Do you think I can do a PR using the condition design above?
For the record, we are currently "achieving" this for a public code template by having the host line commented out, asking developers to un-comment it, and also by providing a azd environment variable that turns on the relevant Bicep modules. It's not super elegant, but it's the least code approach we could find: https://github.com/Azure-Samples/azure-search-openai-demo/commit/0225f751f75c4d7149b35f1d88a17cab5a041ab0
@codeazon I'm curious as to your company's needs, you have situations where you sometimes want to deploy to some hosts and sometimes to others? We thought that maybe such a situation was only common for public templates with disparate developers using them.
We want to deploy some services, but not all.
For example, in dev environment, only need to deploy Service A and Service B. But no need to deploy Service C.
Thank you for the feedback! It seems we have a couple of strong options to consider in supporting this feature request:
I’m leaning towards option 2, as it offers more flexibility for end users. This would address the selective deployment scenario and could also support other use cases where only a subset of azd commands need to be executed.
I just discovered that for our conditional deployment situation, we need to use different hooks for App Service vs ACA, prepackage vs prebuild. Would option #2 make that flow easier, perhaps?
I just discovered that for our conditional deployment situation, we need to use different hooks for App Service vs ACA, prepackage vs prebuild. Would option #2 make that flow easier, perhaps?
If custom workflows are exposed then it would only run service lifecycle hooks for the services being deployed. So as long as your craft the hooks for each service then the workflows can direct the correct behavior.
It might look something like this:
# azure.yaml
workflows:
bar:
steps:
azd: deploy foo
azd: deploy bar
services:
foo:
project: ./foo
language: py
host: appservice
hooks:
postdeploy:
run: ./postdeploy.sh
bar:
project: ./bar
language: py
host: function
hooks:
postdeploy:
run: ./postdeploy.sh
Execute the custom workflow: azd workflow run bar
In this particular example it would deploy foo
followed by bar
services. Each services hooks would be run. If you wanted to then expose another workflow with select services deployed you can then also author that as well.
Hello. Is this working now? Or are we waiting for a PR? Can I help and contribute that PR?
Hello. Is this working now? Or are we waiting for a PR? Can I help and contribute that PR?
No, not yet - we're still brainstorming ideas at the moment. Please share your thoughts on any of the ideas mentioned above as we continue to triage this issue.
Our situation: we have an appservice host, and if the user sets a current azd variable, we also want to deploy a functionapp for an additional microservice.
We discussed this in an internal teams thread here: https://teams.microsoft.com/l/message/19:ug5DKpbpRJbBtgoSQAXdynHgthpALgePNJ8wb5AI8HM1@thread.tacv2/1708030654691?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47&groupId=c99e8504-1250-4d95-a824-9778e0e626c7&parentMessageId=1708030654691&teamName=Azure%20Developer%20CLI%20(azd)%20Partners&channelName=General&createdTime=1708030654691
Here's a syntax that Victor suggested:
That would work perfectly for our use case.
And he even suggested that we could switch the platform (like to change between AppService and ACA):
Without this feature, I think we will end up having to use the Azure CLI for the deployment, or forcing developers to un-comment, which is quite inelegant and prone to error.
Thanks!