[Issue] Deploying multiple apps in one repo, in an order

[justinyoo]

Hi, Team.

I've got a question about the azure.yaml schema. According to the schema definition:

https://github.com/Azure/azure-dev/blob/eac24ababa2961eec3ccad3317810227e2fe009f/schemas/v1.0/azure.yaml.json#L44-L46

I might be able to handle multiple app deployments within a repository because the services attribute is the type of dictionary. But the dictionary doesn't guarantee the order of the deployment execution. If I define multiple apps like AzFunc1 and AzFunc2 in azure.yaml, and I need to deploy AzFunc1 first, followed by AzFunc2, can I achieve it as of today, or it's on your roadmap?

[karolz-ms]

I will let other team members comment on the plans, but let me ask you this @justinyoo : can you give us an example situation where dependencies between services cannot be handled via ARM and you need to have multi-stage deployment, with different Bicep files being deployed sequentially?

[justinyoo]

@karolz-ms As far as I properly understand, azure.yaml is responsible for the app deployment, while Bicep takes care of resource provisioning. I can provision both function apps one after the other through bicep. But it's not relevant to the app deployment.

In the Microservices architecture, one API app can have dependency on the other API app. It should be fine as long as the dependencies can be managed through bicep - appsettings resource. But if it's not possible for some reason, we need to manually resolve it, and the deployment order could be one approach.

[karolz-ms]

@justinyoo got it, thanks. What you can do today is deploy a single service (azd deploy --service xxx). Would that (together with a script to call azd deploy commands in right order) be sufficient for your scenario?

[justinyoo]

Oh, that could be enough for now! Hoping I can do the whole thing with the azd up command soon.

[karolz-ms]

Super, glad that you are unblocked.

But regarding long-term plans... I am not sure about adding the concept of app service deployment order to azd. One can argue it is an anti-pattern, and that app services should be resilient enough to be deployed in any order.

[ellismg]

We used to allow finer grained control of the deployment order, back when the services property was an array of services instead of map of service names to settings, since we would deploy services in the order they were listed in the array. When we moved to the map, we changed this to deploy services in order based on their names, with the thought that we could add a dependsOn at a latter point.

I suspect that we may want to encode some dependency information between services at some point (docker compose has a dependsOn story that may be useful to look at for inspiration) and then use that to drive deployment. I understand the anti-pattern argument, but this does feel like a common enough pattern that we'll want to support. I suspect we will also end up wanting to leverage this in our templates at some point.

[ellismg]

Do be explicit - in addition to what @karolz-ms mentions (using the --service argument to deploy just a single service and then orchestrating that with a script) will work. In addition - we do guarantee today when deploying services we deploy them based on the sorted ordering of the of their friendly names (i.e. the names of the keys in the services object) and if we were to change that, we'd call it out in the CHANGELOG.md

[aaronpowell]

I've just come across a need for this feature, so I'll add another scenario on top of what @justinyoo outlined: static site generation of JavaScript applications.

I'm building a Next.js app that will deploy to Container Apps, and during the npm run build phase, it needs to talk to the CMS backend (deployed to another Container App) to get some data that is used to pre-generate the pages (using this feature).

For this to work, I need the CMS deployed, and we'll then pass that URL as an environment variable to the npm run build command so that it can pull some data from the CMS.

With JavaScript sites, whether they are using Static Site Generation (SSG) or Server-Side Rendering (SSR), the need to connect to an external resource to get data during the "build" process isn't that uncommon.