Version control for Azure Logic Apps with PowerShell

Last updated on February 20, 2025
Whenever people develop Azure Logic Apps, they tend to forget to do one thing: commit the changes into a version control system. Because the development happens in a web browser and not a code editor where you can easily check in your changes, you are typically required to perform the following steps:
- Open the logic app in the code view
- Copy-paste the code to a JSON file
- Check in the file changes into version control
Tedious, right?
But that is not even the most significant issue. The main problem is that people keep on forgetting to do those steps every time they modify the logic apps. And if a solution consists of several logic apps, the process becomes even more forgettable.
Additionally, depending on which way you open the code view (do you switch to it from the edit view or go to it directly), the resulting JSON is slightly different. The JSON being slightly different means that even though the logic has not changed, comparing versions would show differences simply because the JSON elements are in different order. Grrr!
To address these pain points, I first checked if the Visual Studio Code Logic App extension. I was hoping it’d allow me to develop logic apps in VS Code, which again would allow me to check in the changes to version control effortlessly. However, it only allows you to edit the JSON markup and then preview your changes in a read-only graphical editor. It doesn’t allow you to perform graphical programming like the logic app designer you use in the web browser. Weird. I wonder if anyone actually uses the extension.
So, I ended up writing a script to read the latest changes from Azure and check them into version control. It addresses the issues in the following manner.
- With a script, backing up logic apps to version control is much more pleasant than doing it manually.
- To avoid forgetting to run the script, you can schedule it to be run automatically, e.g., at the end of each day.
- When the logic apps JSON is fetched with PowerShell every time, it ensures the elements are always in the same order, and no unnecessary changes are committed. It makes checking what has actually changed between versions way easier!
The script
Before you run the script, you need to create a repository for the JSON files in your version control system and clone that repo on your machine. Then, modify the script variables at the top to match your environment. When the variable values are set in the script, you do not need to provide them as input every time. The only parameter you need to provide is the commit message if new changes are detected (and, optionally, the branch name if you prefer not to use a default value).
The script checks if a JSON file matching the logic app name can be found in the repository root. If the file does not exist, it will be created, so you do not need to create an empty file in advance.
Further development
Now, this script is only the first step. Currently, it needs to be run on a developer’s machine. Ideally, you do not want to count on developers remembering to run a script or going through the trouble of scheduling it on their machines. Instead, you could run the script (with modifications regarding authentication) on an Azure Function App. The function would run regularly and ensure the latest logic app version is always backed up. You could utilize Azure AI to write a short commit message based on the detected changes or simply use a default message every time. It is a higher priority to ensure the code is always backed up than to be able to provide an optimal commit message.
Another thing you might also want to consider is implementing CI/CD pipelines if you have multiple environments. When new changes are detected in a version control branch, it can kick off a CI/CD pipeline. The pipeline can then automatically deploy those changes to other environments (with optional approval gates). You can deploy the logic app changes either with PowerShell or Bicep. The benefit of Bicep is that it also creates the logic app resource if it does not yet exist, and when all updates are done via Bicep, it helps you avoid configuration drift.
Afterword
I hope you find the script useful and that you will keep your logic apps timely backed up in version control from now on. If you’d like to be notified whenever I publish more content, you can follow me on LinkedIn or subscribe to my blog via the sidebar (at the bottom on mobile).
Happy developing, and until next time!
Laura