Logic App CI/CD - why is workflow treated as infrastructure?

Question

I am using Logic App in one of my projects and I thought it would be nice to use Azure Pipeline, even to just learn about CI/CD. I already figured out how to do CI/CD with Azure Function (another part of my project uses Functions). However, Logic Apps are a bit weird. All examples I've seen use ARM templates to deploy the Logic App (MSDN example).

This means that I would not only deploy my Logic App's workflow, but also the Logic App resource in Azure as well. Why is that?

In the case of Azure Function code, I have an Azure Function resource in Azure that I did set up manually, and in the pipeline, I just deploy the code to it - I do not require infrastructure deployment. So, the steps in the pipeline are similar to:

1. Build the Function app
2. Deploy the code to Function

Now, with the addition of the Logic App, it will start to look like this:

1. Build the Function app
2. Deploy the code to Function
3. Deploy Logic App resource (workflow included in the ARM)

The issues I see:

1. IaC would be nice if all my infrastructure was in ARM. I do not really intend to have it (I am too lazy to do it for azure functions, table storage, and the rest of my resources :P). I don't want to have partly Infrastructure as Code.
2. Why is Logic App's workflow treated as part of ARM? I feel it's as if my App Service's ARM would contain C# code. Weird!
3. In Logic App's ARM I have to specify values for workflow's properties. I don't want that. I treat these properties like the Configuration of an App Service. I don't want to keep these values in my repo. I want to be able to change it whenever I need in a Logic App in Azure (like I can change Configuration of Azure Function) and I want these values to not be modified when I run my pipeline!

Am I missing something?

Answer 1

Find the answers to your questions below.

IaC would be nice if all my infrastructure was in ARM. I do not really intend to have it (I am too lazy to do it for azure functions, table storage, and the rest of my resources :P). I don't want to have partly Infrastructure as Code.

With businesses moving toward digitization, logic apps help you connect legacy, modern, and cutting-edge systems more easily and quickly by providing prebuilt APIs as Microsoft-managed connectors. That way, you can focus on your apps' business logic and functionality. You don't have to worry about building, hosting, scaling, managing, maintaining, and monitoring your apps. Logic Apps handles these concerns for you. Plus, you pay only for what you use based on a consumption pricing model.

In many cases, you won't have to write code. But if you must write some code, you can create code snippets with Azure Functions and run that code on-demand from logic apps. Also, if your logic apps need to interact with events from Azure services, custom apps, or other solutions, you can use Azure Event Grid with your logic apps for event monitoring, routing, and publishing.

Why is Logic App's workflow treated as part of ARM? I feel it's as if my App Service's ARM would contain C# code. Weird!

It is how the way it is designed. If you don't want workflow (which will be in ARM templates), you can opt for services like Azure Functions - but here you will have to write, maintain and manage your code on your own.

In Logic App's ARM I have to specify values for workflow's properties. I don't want that. I treat these properties like the Configuration of an App Service. I don't want to keep these values in my repo. I want to be able to change it whenever I need in a Logic App in Azure (like I can change Configuration of Azure Function) and I want these values to not be modified when I run my pipeline!

If you deploy to environments for development, test, and production, you likely use different connection strings for each environment. You can declare template parameters that accept different connection strings and then store those strings in a separate parameters file. That way, you can change those values without having to update and redeploy the template.

For scenarios where you have parameter values that are sensitive or must be secured, such as passwords and secrets, you can store those values in Azure Key Vault and have your parameters file retrieve those values. However, in these scenarios, you'd redeploy to retrieve the current values.

To gain more information about Logic App and this topic, you can visit below links of MSDocs:

• Overview - What is Azure Logic Apps?

• Overview: Automate deployment for Azure Logic Apps by using Azure Resource Manager templates