Recently we have been working with our audit team and we have had a lot of success demonstrating the process we use for managing the ALM side of the interfaces we have built with Logic Apps. In this article I wanted to talk a little about what we do to share with other teams and also generate conversation around good practices.

This is a bigger topic really and ill probably talk more in future posts about things outside of a specific deployment but today ill focus more on the actual deployment of a Logic App.

First off we use tags in the ARM template for consumption Logic Apps. You can see below a snippet from the template showing some of the common tags we use.

 "resources": [
      "name": "LA-Name",
      "type": "Microsoft.Logic/workflows",
      "location": "[parameters('arm_logicAppLocation')]",
      "tags": {
        "displayName": "LA-Name",
        "logicalResource": "LA-Name",
        "description": "what does this resource do",
        "devOps:BuildNumber": "__BUILD_BUILDNUMBER__",
        "devOps:BuildDefinition": "__BUILD_DEFINITIONNAME__",
        "devOps:Repo": "__BUILD_REPOSITORY_NAME__",
        "devops:ReleaseDefinition": "__RELEASE_DEFINITIONNAME__",
        "devops:ReleaseName": "__RELEASE_RELEASENAME__",
        "Project Name": "[The name of the project that delivered the interface]",
        "Environment": "[parameters('arm_environmentname')]",
        "costCentre": "[Who pays for this]",
        "dataProfile": "Internal",
        "documentationLink": "[url goes here]",
        "managedBy": "",
        "ownedBy": "[Team who own interface]",
        "scope": "[parameters('arm_scope')]",
        "interfaceCatalog:WorkItemID": "43585"

A list of the key tags we care about for deployment audit are:

logicalResourceThis represents a name for the resource which is not environment specific. Sometimes you need to include the environment name in a resource which means you cant easily see which is the same 2 versions of a resource in 2 different environments. For Logic Apps this isnt so much of an issue except we have had some challenges with this when setting up a managed identity in the past where the name needed to be unique but this tag helps us relate resources across environment
descriptionThis tag is used to give a short text overview of what the logic app does
documentationLinkThis would be a link to a page in our Azure DevOps wiki or an md file in a repo which would be an overview of what the logic app does and how it works.
devOps:BuildNumberThis contains the build number from the pipeline that created the deployment artefact
devOps:BuildDefinitionThis contains the name of the build pipeline that the artefact being deployed came from
devOps:RepoThis contains the name of the repo where the code is for this logic app
devops:ReleaseDefinitionThis contains the name of the release pipeline
devops:ReleaseNameThis contains the release name which is the run of the release pipeline. EG Release-24
interfaceCatalog:WorkItemIDThis is populated with the id which matches a work item in Azure DevOps which is a unique id for the interface in our interface catalog.
Note – Ill talk about this in a future blog post but this gives us tracability from the logic app back to a central interface catalog and then tracability to requirements which change the interface over its lifecycle.
managedByThis is the name of the team who managed the support of this resource
dataProfileThis is the profile of data classification for data going through this logic app
costCentreThis is the cost centre for the bill payer for this resource
ownedByThis is the business owner for the interface that this Logic App implements

Some of the values for the tags can be hard coded and others are injected at deployment time. You might notice above on some of the tags in the code snippet we have the __[variable]__ format which we can inject items in using the Replace Tokens task in a devops pipeline as shown below.

The next thing we do for the Logic App deployment via the ARM task is to set the deployment name to this variable


Doing this means that when we do a deployment then the Azure Deployments list will show the ARM deployment and it will use the name of the release pipeline and its run name in the deployment list. This means that we can easily trace a deployment to a pipeline run. You can see the updated release names in the Azure Deployments below.

Within a consumption Logic App I also have the versions feature which shows me each time a Logic App has changed and I can see the version history.

Having an auditable process is about being able to demonstrate traceability within your process. From a Logic App a diagram representing how our tracability from a deployment through to devops pipelines etc would look something like below.

It would be interesting to see how others are doing stuff to compare and contrast with our approach


Buy Me A Coffee