In this section, we will cover continuous integration and deployment for the Logic Apps workflow. The process of deploying the Logic Apps workflow is similar to the process with other Azure resources. There are some basic differences, such as how we can manage API connection resources and the actual naming convention you should adhere to for the API connection. The API connection resource can be managed either through an individual Logic Apps workflow definition or you can have a separate ARM resource to manage Logic Apps API connection properties.

In this section, we will separate the API connection resource from Logic Apps, and we'll try to describe how easily you can enable continuous integration and deployment for Logic Apps and manage API connection resources through a DevOps process:

1. The first step here is to create a blank Azure resource project through Visual Studio Code or Visual Studio 2015 or later:

2. Next, we will add the definition of Logic Apps API connection properties in the ARM template definition file. You can get the basic definition for the API connection through an Azure portal automation script. For example, the Service Bus API connection definition is described here:

{
  "type": "Microsoft.Web/connections",
  "apiVersion": "2016-06-01",
  "name": "[parameters('servicebusname')]",
  "location": "[parameters('apiresourcelocation')]",
  "properties": {
    "api": {
      "id": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Web/locations/', parameters('apiresourcelocation'), '/managedApis/servicebus')]"
    },
  "displayName": "Azure Servicebus",
  "parameterValues": {
    "connectionString": "[parameters('azuresbconnectionstring')]"
    }
  }
}

3. Let's add another API connection resource, such as Cosmos DB, SFTP, Azure Event Grid, or Office 365, and parametrize the required connection properties to enable API connection deployment through the DevOps pipeline:

{
  "type": "Microsoft.Web/connections",
  "name": "[parameters('cosmosdbconnectionname')]",
  "apiVersion": "2016-06-01",
  "location": "[parameters('apiresourcelocation')]",
  "scale": null,
  "properties": {
    "displayName": "cosmos database connection",
    "customParameterValues": {},
      "api": {
        "id": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Web/locations/', parameters('apiresourcelocation'), '/managedApis/documentdb')]"
      }
    }
}

4. Like SQL Server API connections, some API connections require authentication properties, which you can add in the parameter section. In the following example, we have added a SQL Server API connection with server details such as the server name, the database name, and user credentials:

{
  "type": "Microsoft.Web/connections",
  "apiVersion": "2016-06-01",
  "name": "[parameters('sqlserverconnecitonName')]",
  "location": "[parameters('apiresourcelocation')]",
  "properties": {
    "api": {
      "id": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Web/locations/', parameters('apiresourcelocation'), '/managedApis/sql')]"
    },
    "displayName": "SQL Server API Connecton",
    "parameterValues": {
      "server": "[parameters('sqlserverName')]",
      "database": "[parameters('sqldatabaseName')]",
      "username": "[parameters('sqluserid')]",
      "password": "[parameters('sqlpassword')]"
    }
  }
}

5. Once all your connection properties are listed in the ARM definition along with an appropriate parameter listing, test the connection property by manually deploying it through Visual Studio:

To verify that your Logic Apps API connection is deployed successfully, you can log in to the Azure portal and navigate to the resource group that you selected when doing a manual deployment.

• Now that the API connection is a separate resource, you have much more control over the number of API connections created in the Azure resource, and you can also control the API naming convention when you have a distributed team working on a cloud integration framework using a Logic Apps workflow:

• Next, add the logic API connection resource in DevOps source control and build a continuous integration and deployment pipeline for multiple environments.
• Logic Apps API connection resources are ARM templates, and the build definition for API connection resources will follow the same steps as Service Bus and Event Grid resources.
• To implement DevOps, add a build task and Publish build artifacts and enable the trigger for continuous integration:

• In the release pipeline for the Logic Apps API connection project, we use a single task to create or update the Azure resource group with the API connection definition.
• The Logic Apps API connection resource project will contain a single API definition file, along with multiple parameter files for different integration environments (UAT, DEV, PROD, and SIT):

The release process can be either triggered manually, scheduled, or enabled through a continuous deployment trigger. In this case, we have used a manual process to create a release to a different environment using the service principal for multiple Azure subscriptions:

After the deployment of the Logic Apps API connection, it takes time to create an automated deployment process for a Logic Apps workflow because you can create a Logic Apps workflow in different IDE environments, such as Visual Studio 2015 and Visual Studio Code, or through the Azure portal. To automate Logic Apps deployment across multiple environments, it is essential to parameterize the raw Logic Apps workflow definition file, which you can find in the Azure portal or Visual Studio. To get the existing Logic Apps workflow definition file, you can use Visual Studio Cloud Explorer to copy the raw definition file from the Azure portal resource group.

In this example, we will use existing HTTP trigger Logic Apps and import the definition into Visual Studio to perform the required automation steps:

To open the Logic Apps definition file in Visual Studio, you need to authenticate your Visual Studio account against the Azure subscription running Logic Apps. Once the authentication is done, you can open Logic Apps with the Logic Apps editor and download the definition:

The next step is to parameterize the Logic Apps definition file in Visual Studio and update the DevOps source control with the updated Logic Apps workflow definition:

Once you are done modifying the raw Logic Apps workflow template with the appropriate parameter list, you can push your changes to the DevOps portal, where we can build an automated build and release pipeline. Here is the build definition for Logic Apps:

You can also group multiple Logic Apps definition files within a single ARM template resource. The Logic Apps release will contain one or more resource group tasks, which will deploy Logic Apps into the required resource group and subscription.

Grouping Logic Apps resources into the same definition file, based on business process, allows you to segregate resources and deploy them as individual components. As Logic Apps are built on a microservices model, any changes to certain Logic Apps or groups will not affect the processing of other Logic Apps within the same resource group:

Next, we update the Logic Apps template source code through Visual Studio or Visual Studio Code with the enabled continuous integration/continuous delivery trigger on build and release. We should see the actual Logic Apps resources being deployed through multiple environments (in this case, Development, UAT, and Production):

With that, we have completed this DevOps chapter. If you want to learn the basics of the ARM template, go through the Microsoft documentation at https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-authoring-templates. This will help you to work effectively for any resource deployment through the ARM and DevOps processes.