Azure / azure-dev

A developer CLI that reduces the time it takes for you to get started on Azure. The Azure Developer CLI (azd) provides a set of developer-friendly commands that map to key stages in your workflow - code, build, deploy, monitor, repeat.
https://aka.ms/azd
MIT License
410 stars 197 forks source link

[Issue] Enable azure.yaml to specify optional deployments for services #3514

Open pamelafox opened 8 months ago

pamelafox commented 8 months ago

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: image

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): image

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!

jongio commented 8 months ago

Related #3272

ellismg commented 7 months ago

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.

wbreza commented 7 months ago

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.

codeazon commented 1 month ago

My company needs this as well. Do you think I can do a PR using the condition design above?

pamelafox commented 1 month ago

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.

codeazon commented 1 month ago

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.

wbreza commented 1 month ago

Thank you for the feedback! It seems we have a couple of strong options to consider in supporting this feature request:

  1. Provide a way to define deployment conditions for a service.
  2. Expose customizable workflows where users can selectively run specific sub-commands.

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.

pamelafox commented 1 month ago

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?

wbreza commented 1 month ago

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.

codeazon commented 1 month ago

Hello. Is this working now? Or are we waiting for a PR? Can I help and contribute that PR?

wbreza commented 1 month ago

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.