DevOps for Azure Logic Apps Standard

Azure Logic apps standard is built on top of Azure function runtime. This means Logic App standard enjoys most of the features Azure function provides.

Azure Function Runtime (Image from techcommunity.microsoft.com)

Azure Logic Apps Running Anywhere - Runtime Deep Dive

When it comes to DevOps story, Azure function supports Zip deployment model. Logic App standard enjoys the same model to deploy the workflows. Every time when the build pipeline runs it zips up the workflows in the source code and zips it up and release pipeline replaces the existing files from the target app service and extracts the new zip file. This works well for deployment every time. This also maps a source control repository to a Logic app standard. It creates a tight 1:1 integration.

Zip push deployment for Azure Functions

But this also highlights the limitations with this deployment model.

1. What if I just want to deploy my workflows in a logic app incrementally?
2. What if I want to deploy a feature I have developed on a different repo to deploy to the existing Logic App?

I have recently got in to this situation where repositories were created per feature, but the workflows created on these repos belonged to a single Logic app. With the zip deployment model, this would always wipe out the existing workflows and create only the new workflow in the new repository. This included parameters, app settings and connections.

To avoid this may be we could go for a single repository where the complete list of workflows and all of its properties in the same place, but what if we have a different schedule for each features? We will end up redeploying the complete list of workflows requiring to plan for a very troublesome regression test.

There doesn’t seem to be an out of the box support for incremental deployment for Logic App standard at the moment.

We had implemented the solution in the following way. Keen to hear if there are any other approaches tried.

1. Download publishing profile:

Publishing profile would lets us identify the credentials used internally to make REST API calls.

2. Download the existing package:

REST API · projectkudu/kudu Wiki

3. Pull package from the source code

4. Merge the workflow folders

5. Merge parameters.json

6. Merge connections.json

7. Merge application settings

8. Prepare the final package