Rethinking an old Logic App deployment package – Part I

Some time ago I had the opportunity to work on a big Logic Apps implementation. The project was a big success and I’ve learned a lot… but one thing always bugged me on that project: the way I’ve tackled deployment. It was a mix of me, my team getting used to logic apps and the tooling still on early stages.

Almost a year later and I have the opportunity to revisit this deployment setup, as I’m working on some updates in the logic apps. So I’m taking this opportunity to try to create the deployment package the way I think it should be. My plan is to document the new “thinking”, any gotchas and tools I’m using along the way. So expect a series of blog posts as this evolves.

Current Deployment

The current deployment project looks like this:

• Two ARM templates:
  • The first template deploys a whole set of slow-changing components – azure functions web site (but not the associated code), service bus topics and subscriptions.
  • The second template have all the Logic Apps from the project.

Having more than one template is a good thing in this case, as I don’t have to redeploy the functions and service bus every time I change logic apps. But I would like to breakdown the logic apps in individual templates too, as right now if I want to deploy just the changes I’ve made in a single logic app, I have to manually extract that logic app and create a subset of a deployment package. Also bringing changes back to the deployment package takes time as I have to compare the changes made in the online editor with the full script and find where to apply the changes, instead of simply updating a file.

End Goal

My end goal is to have something like this:

• Individual ARM templates for each azure resource.
• Use nested templates to create a couple of “master templates” – one for the slow-changing components and one for logic apps templates.

What I want ultimately is to be able to deploy a single logic app if this is the only resource that is changing. This section of the ARM Templates Best Practices expands on this topic.

First things first

Before I go ahead and can play with the wonderful world of nested templates, I need individual templates first. Templates for the slow-changing components is easy, I can break them down from the existing template. The logic apps on the other hand are quite big, so I need some process (ideally automated) that allow me to extract them from the portal – cue to Jeff Hollan’s Logic App Template Generator. Jeff created a Powershell module that allow you to point to a Logic App that you have access in Azure and generate an ARM template and a parameters file from that. I’ve been playing with this module, and creating a powershell script that allow me to extract all logic apps associated to a specific resource group. We will be discussing this on the next post. See you there.