[Feature] azd provision only deploying changed infra

[johnnyreilly]

• [x] Make sure you've installed the latest version using instructions in the wiki

Output from azd version N/A

Describe the bug An amazing feature shipped with azd 1.4: https://devblogs.microsoft.com/azure-sdk/azure-developer-cli-azd-october-2023-release/#azd-provision-is-now-faster-when-there-are-no-infrastructure-changes

If you’ve been using the Azure Developer CLI for a while, you may have noticed that sometimes azd provision takes a long time to complete when it may not need to. The wait time was because, prior to version 1.4.0, azd provision would always reprovision regardless of whether the underlying Infrastructure as Code had changed. In other words, if you ran azd provision multiple times in a row without changing your code, you would have to wait for the same deployment to complete multiple times.

This is great. But it could be more powerful. Roughly speaking, when using this feature there are two potential outcomes:

1. Reprovision all infrastructure
2. Do not reprovision all infrastructure

There is not a middle ground. Imagine you're deploying a container app and a Cosmos DB. In your latest deployment you change one property of the container app. Ideally you would only reprovision the container app. Alas, at present, azd will reprovision both the container app and the database.

To Reproduce N/A

Expected behavior Ideally, azd would be smart enough to only reprovision the changed infrastructure.

Environment N/A

Additional context You can read more about what lead me to raise this issue in this post: https://johnnyreilly.com/using-azd-for-faster-incremental-azure-container-app-deployments-in-azure-devops

[vhvb1989]

Hello @johnnyreilly . I'm glad to hear you liked that feature!

Your suggestion makes total sense, however, the current azd provision design does not allow such feature. From azd's current perspective, the infrastructure-as-code is composed by a definition template (either bicep or terraform) and template-inputs and the template is an atomic peace to azd. Azd has no visibility the list of Azure resources inside the template.

There is some work in progress around azd composability which might help for the use case you described. You can see more about it here: https://github.com/Azure/azure-dev/issues/3072

And we also have talked in the past about supporting infrastructure files per service as a way to divide the currently one only infra template into a common template + unique deployments per service. But that's also in the backlog only

[johnnyreilly]

Thanks for responding @vhvb1989. The linked issue is interesting.

I've no doubt you've discussed this already, but on the off chance it hasn't come up, I thought I'd throw this into the mix:

My bicep codebase is already modular. I have a main.bicep file which internally triggers deployment of distinct modules for Azure Container Apps / Cosmos DB etc. When deployed, each will result in a separate sub deployment in the Azure Portal with distinct inputs.

I guess I was rather hoping that AZD could work at that level. But from what you've said maybe that's unlikely. Thanks though!

[vhvb1989]

It's a place we want to go, for sure, @johnnyreilly , it is just taking some time.

What makes it a little bit complicated is that, bicep files are first converted to an ARM Json file. The main.bicep and all modules are parsed and combined to build one single json file, which is what azd uses as payload to Azure. Parsing the JSON file to figure the ordering (based on relations) and submitting each deployment happens on the server side. During the process, azd only pulls the progress. This means that, once azd submitted the deployment, you can stop azd but the full deployment will continue on the server