Improving the DevOps Experience for Azure Logic Apps Standard
Published Apr 29 2024 02:34 PM 2,035 Views
Microsoft

With the trend towards distributed and native cloud apps, organizations are dealing with more distributed components across more environments. To maintain control and consistency, you can automate your environments and deploy more components faster with higher confidence by using DevOps tools and processes.

 

Azure Logic Apps Standard just launched a set of preview features that help you automate the steps in setting up DevOps processes for your applications. In this blog post, you will find more about these new features:

 

 

 

Parameterize connection references

 

Connectors in Azure Logic Apps enable seamless integration with external systems and services across different protocols, platforms, and authentication methods. Azure Logic Apps Standard separates the physical and logical aspects for connectors thanks to the connection reference file (connections.json), which maps the connections used in workflows to live connections using Azure Resources, Azure Functions, Azure API Management and in-app references).

 

Until now, these references were tied to the connection that you defined at design time, which made the process to abstract the code for multiple environments a manual process. However, starting with the Visual Studio Code extension for Azure Logic Apps version 4.4.3, connections are parameterized by default, which simplifies the process of deploying these applications to other environments.

 

What does connection reference parameterization look like?


In the connections.json file, new managed connections look like the following template:

 

 

 

 

 

 

 "myconnection": {
      "api": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/providers/Microsoft.Web/locations/@{appsetting('WORKFLOWS_LOCATION_NAME')}/managedApis/connectorname"
      },
      "connection": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/resourceGroups/@{appsetting('WORKFLOWS_RESOURCE_GROUP_NAME')}/providers/Microsoft.Web/connections/myconnection"
      },
      "connectionRuntimeUrl": "@{appsetting(myconnection-connectionRuntimeUrl')}",
      "authentication": "@parameters(myconnection-connectionAuthentication')"
    }

 

 

 

 

 

 

Property

Parameterization

api.id

Subscription and location are derived from app settings.

connection.id

Subscription and resource group are derived from app settings.

connection.connectionRuntimeUrl

This value is derived from app settings. The app setting key is defined as <connection_reference_name>-connectionRuntimeUrl.

connection.authentication

This value is derived from the parameters file. The key is defined as <connection_reference_name>-connectionAuthentication.

 

For connection authentication, a new entry is created in the parameters file, per the following template:

 

 

 

 

 

 

  "myconnection-connectionAuthentication": {
    "type": "Object",
    "value": {
      "type": "Raw",
      "scheme": "Key",
      "parameter": "@appsetting(myconnection-connectionKey')"
    }
  }

 

 

 

 

 

 

Note: As a secret, the connection key is referenced in your app settings. Connection keys have different values for local and Azure deployments. When deployed to Azure, the connection key value should reference the managed identity associated with your Standard logic app resource. The latest Visual Studio Code extension also has the capability to auto-generate deployment scripts, which makes sure that you have a ready-to-use cloud version of the parameters file, so that you don't have to guess at the changes.

 

Opt in for connection parameterization

 

This experience is an opt-in for you as you might already have projects in flight that use your own solution for parameterization. After you install extension version 4.4.3, you get the following pop-up message during new project startup: 

 

WSilveira_0-1714342313258.png

 

Option

Action

Yes

This option enables connection parameterization and updates any project that you open with the new parameterization capability.

No

This option doesn't enable parameterization for your current project but asks again the next time that you open a project.

Don’t warn again

This option opts out from the parameterization feature and doesn't show the message again. However, you can opt in later at any time.

To opt in later, go to the extension settings in Visual Studio Code and select the following option:

WSilveira_1-1714342313260.png

 

 

 

Automate deployment scripts generation

 

You can generate ARM templates and Azure DevOps pipelines to support deployment automation for your Standard logic apps, starting with the Visual Studio Code extension for Azure Logic Apps Standard version 4.4.3.

 

WSilveira_2-1714342313262.png

 

For more information and full walkthrough that shows how to generate and connect these templates to your Azure DevOps platform, see our official documentation at Automate build and deployment for Standard logic app workflows with Azure DevOps.

 

Azure Logic Apps Build and Release Actions for Azure DevOps

 

Two new actions now exist for Azure DevOps, which the Visual Studio Code extension uses to generate build and release pipelines: 

 

  • Azure Logic Apps Standard Build
  • Azure Logic Apps Standard Release

Before you can use this new pipeline capability, you must first install these actions, which you can find on the Visual Studio Marketplace.

 

 

Enable zero downtime deployment scenarios

 

To deploy mission-critical logic apps that are always available and responsive, even during updates or maintenance, you can enable zero downtime deployment by creating and using deployment slots. Zero downtime means that when you deploy new versions of your app, end users shouldn't experience disruption or downtime. Deployment slots, which are now available in public preview for Azure Logic Apps, are isolated nonproduction environments that host different versions of your Standard logic app and provide the following benefits:

 

  • Swap a deployment slot with your production slot without interruption. That way, you can update your logic app and workflows without affecting availability or performance.
  • Validate any changes in a deployment slot before you apply those changes to the production slot.
  • Roll back to a previous version, if anything goes wrong with your deployment.
  • Reduce the risk of negative performance when you must exceed the recommended number of workflows per logic app.

 

For more information, see our official documentation at Set up deployment slots to enable zero downtime deployment in Azure Logic Apps.

5 Comments
Co-Authors
Version history
Last update:
‎Apr 29 2024 02:45 PM
Updated by: