Advanced | Flow of the Week: Tracking changes in a deployment
In a previous blog, we saw how the Microsoft Flow team tracks Flow portal and backend deployments as they get deployed across regions. While knowing which builds are deployed to which region helps during a live site investigation, an equal if not more important piece of information is knowing what changes were deployed as part of a build. Knowing what changes comprise a build and where it is deployed helps assess the impact of a live site incident and take corrective actions accordingly. However, knowing which changes are being deployed also helps in the following ways:
- Generate e-mail based alerts when the current candidate build gets deployed to first release region. Engineers and Product Managers can check if their bug fixes or features are making to production, and if so, validate it end to end on production. This also serves as a callout for test team to switch to testing the service on production and, especially, focus on the new features or bug fixes that are being rolled out.
- Generate e-mail based alerts when the deployment to all regions completes. This is especially useful for Product Managers as they can publish blogs announcing new features. They can also work with partner teams to plan out next steps for a big feature and update customers about blocker bug fixes and / or new features that the customer was waiting for.
- Track which particular change was deployed to which regions and when. This helps the engineering team to ensure that a backend change – on which a front end feature depends – has been deployed to all regions before enabling the corresponding front end feature on production.
We will look at a Flow that enables each of the above scenarios and helps improve decision making across all roles on the team.
Solution
We used two SharePoint lists in the previous blog to determine when a deployment finished and what changes were deployed as part of the deployment. The lists were:
- Current deployments snapshot: To record the branch and build that was deployed to each role in each region.
- Deployments history: To record the history of branch and builds deployed to each role in each region.
We trigger our Flow when an item in the Current Deployments snapshot list is updated.
Once our flow is triggered, we need to check if the deployment was to a first release region or not. We do this by using an advanced condition to evaluate all possible combinations for a first release deployment.
If this deployment is to a first release region, we send a mail with the log of changes contained in this build – we will look at how we get the log of changes later in the blog. However, if the deployment is to some other region, we check if this is the last deployment for this build. We do this by checking if the Current deployment snapshot list has any items that do not have the candidate build deployed on the same role across regions.
If there are no items in the Current deployment snapshot list that have a different build, it means that deployment to all regions completed. At this point, we get the list of all regions to which the current candidate build was deployed and create a table containing columns for the region name and the timestamp when deployment in that region completed. We then send out a mail containing this table along with the change log table to the team.
Getting change logs in a build
Microsoft Flow’s product code is maintained on Visual Studio Team Services (VSTS or formerly Visual Studio Online). Microsoft Flow also has a first class connector that connects to VSTS. However due to some limitations of the current connector implementation, we used a Custom Connector to connect to VSTS and get the required change log data. The partner team is working hard on bringing the features of Custom Connector into the first class connector. In the meantime, if you do want to build and use similar capabilities in your Flow, it is super simple to build a Custom Connector in Microsoft Flow and the VSTS REST API makes it very easy to get one up very quickly.
Depending on whether we are trying to get change log for the frontend or backend service, we compute the repository id using a simple IF expression. Once we know the repository id, and since we already know the branch name (from the flow trigger), we can get the log of recent changes on the repository. The commit log to identify a candidate build follows a particular pattern, and so, we filter the logs to find the corresponding commit. The output of the filter operation is an array containing a single matching commit log – we extract this object for use in subsequent actions by using a Compose action followed by a ParseJson action.
In order to find which commit log to read up to, we first need to find the previous deployment build information. We do this by searching the Deployments history list to find the deployment that preceded the just completed deployment. We list the top 2 items in the Deployments history list and filter out the item corresponding to the deployment that just completed. We then use the Compose and ParseJson actions to get the deployment item for the previous deployment, again, for use in subsequent actions.
We use the branch name from previous deployment item to get the commit log details for the previous build that was deployed to same role. Now that we have the previous and current commit log details, we get the list of change logs that are contained in the build and filter out some auto generated commit logs to get the list of changes contained in this build.
Pushing change log to Power BI
We use the change log to send out not only the e-mail notifications mentioned earlier, but we also push the data into into Power BI. We created a Streaming Dataset in Power BI with a schema specific to tracking the change log information:
In the flow, once we get the change log information, we iterate over each change log record and push it into Power BI.
Outputs
Now that we have looked at how the flow works, let’s look at the different outputs of the flow. The first mail that gets sent out is the email notifying deployment to first release region – it looks as follows:
The next mail that gets generated is when deployment to all regions completes – this mail lists the regions where deployment finished along with deployment completion time and the changes that were deployed.
Finally, we can use the Power BI report to track which change was deployed to which regions.
Summary
Using Microsoft Flow we were able to develop an end-to-end deployment e-mail notification system and also generate Power BI-based change tracking report without writing a single line of code.
