Automate Resource Recreation in Bicep Deployments

[makdeniz]

Is your feature request related to a problem? Please describe. Whenever we need to change a property of a resource that requires its recreation, we have to manually delete the resource using the Azure CLI or portal, and then rerun the deployment. In a production environment, manual deletion is not possible. Therefore, we need to remove the module from main.bicep, run the pipeline, then revert the changes and run it again.

Describe the solution you'd like It would be extremely helpful if Bicep could manage resource recreation automatically, similar to how Terraform handles it.

[alex-frankel]

Apologies for the delay on this one. I'm wondering if Deployment Stacks can help here. While it would work a little different than TF which has specific metadata to track when it needs to re-create a resource, Stacks could still theoretically optimize the flow you describe.

With stacks, removing the resource from the file will trigger a deletion and then you would add the replacement resource. If you wanted to do it in the same deployment you would have to declare the new resource with a different symbolic name, which might get tricky, but you could have an initial deployment with the resource to be deleted, then run again with the replacement resource.

Thoughts?

cc @azcloudfarmer / @dantedallag

[makdeniz]

@alex-frankel thanks for your response. We are currently using the deployment stack as it's the only method available for deleting resources since no other options are feasible for security reasons. I’m wondering if Bicep can handle situations where changes necessitate creating a new resource. Instead of rejecting the deployment and failing, could Bicep delete the existing resource first and then proceed to create the new one with defined deployment?

[alex-frankel]

In theory, we could extend the functionality of stacks to support this, but a lot of open questions to implementing a system that is sustainable. For example, where does the metadata live on which resource updates require a replacement? Ideally, we can share that with terraform.

We will discuss it as a team this week and circle back if there are any concrete updates. I'm going to move this to the deployment stacks repo for better tracking.

[azcloudfarmer]

Hello @makdeniz - can you share the example resource type for this scenario? Are there more instances of this you can share? Thanks!