Rethinking an old Logic App deployment package- part IV

Previously in Note to self…

I got one step closer to my goal to export all logic apps from a resource group to a Visual Studio project, using linked templates to deploy all logic apps in one when required, but still being able to deploy individual logic apps for a patch template. In previous posts, I’ve managed to use the extend a open source component originally created by Jeff Hollan and maintained by Mattias Lögdberg, adding a couple of extra cmdlets. You can get the last post here.

Visual Studio ARM Deployment Project

For the last step in this process, I needed to create an Azure Resource Manager deployment project. I decided to go through the most pragmatic route – to use an existing project as template. So as a first step, I created an empty Azure Resource Group VS project and tried to find out how artefacts can be associated to it.

Visual Studio project selection

A new project creates the following files:

  • azuredeploy.json – an empty ARM template
  • azuredeploy.parameters.json – an empty ARM paramters file
  • <projectname>.deployproj – the VS project definition
  • Deploy-AzureResourceGroup.ps1 – the powershell script used to deploy the ARM templates
  • Deployment.targets – a build definition file

deployproj is an xml file representing the project components. Analysing the deployproj file, and adding a couple of resources to the project, I found that files are associated to the project using the ItemsGroup element, with the following syntax:

ARM templates are included with the Content build action. A new project would look like this:

Adding a new resource to the project would change it to:

So that gave me the clue I needed to implement the cmdlets that would:

  • Create the required files (<project>.deployproj, deployment.targets, Deploy-AzureResourceGroup.ps1)
  • Include all files I’ve created as part of the previous steps into the ItemsGroup area.

Add-DeploymentVSProject cmdlet

By now I was quite used to the cmdlet classes, so here is how I defined the cmdlet:

  • The cmdle will have a single input parameter called SourceDir, which would point to the folder where the project would be created.
  • A base deployproj, as well as the deployment.targets and Deploy-AzureResourceGroup.ps1 files would be included as embedded resources.
  • BeginProcessing virtual method would be overriden to create all three files – deployproj, targets and ps1 files in the folder.

  • ProcessRecords virtual method would be overriden to include the files to the project. For each subfolder inside SourceDir, a couple of entries would be added to ItemsGroup – one for the template file and another for the parameters file.

The new cmdlet can be invoked by executing this command:

Finalizing Get-RGLogicAppTemplates

So now that the last piece of the puzzle was created, it was just a matter of adding one last line to Get-RGLogicAppTemplates:

That last line would create the VS project files and add the files created in previous steps to the project. The final script looked like this:

In the end was quite pleased with the process. The project that triggered this whole process, where I needed to amend 3 out of 16 logic apps, was deployed with success, with much bigger confidence than I had before, as I could extract the DEV/TEST logic apps and just update those specific parameter files, guranteeing that none of the other logic apps would be redeployed.

Next steps

I could think in a couple of improvements for this process:

  • As you probably noticed, I’ve only created the deployproj file, so there is no Visual Studio solution in this process. It was a concious decision, as I was running out of time to actually use the code to do the real work. Since VS wraps an “orphan” project in a solution, that was a safe bet.
  • Ideally, I would define which environment I would like to create in order to create multiple parameter files.
  • I still need to understand how nested and parent parameter files work, but maybe I could roll up all the parameters to the root parameter files. That might make life easier for full deployment.

I will probably work on some of those items at a later stage or, if you are interested, you might want to fork the project and have a go yourself? ;-D

I hope that you had fun reading this series – I definitely had lots of fun working on this and documenting as I went.

See you next time!

Sharing is caring...

Leave a Reply

Your email address will not be published. Required fields are marked *