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 Logic Apps Running Anywhere - Runtime Deep Dive
For the recently released Azure Logic Apps (Preview) extension for Visual Studio Code, the Logic Apps team redesigned…
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
This article describes how to deploy your function app project files to Azure from a .zip (compressed) file. You learn…
But this also highlights the limitations with this deployment model.
- What if I just want to deploy my workflows in a logic app incrementally?
- 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.
- 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
You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or…
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