{"id":110864,"date":"2017-09-13T07:35:02","date_gmt":"2017-09-13T14:35:02","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/power-platform\/blog\/power-automate\/tracking-changes-in-a-deployment\/"},"modified":"2025-06-11T08:11:59","modified_gmt":"2025-06-11T15:11:59","slug":"tracking-changes-in-a-deployment","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/power-platform\/blog\/power-automate\/tracking-changes-in-a-deployment\/","title":{"rendered":"Advanced | Flow of the Week: Tracking changes in a deployment"},"content":{"rendered":"
In a previous blog<\/a>, 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:<\/p>\n We will look at a Flow that enables each of the above scenarios and helps improve decision making across all roles on the team.<\/p>\n \u00a0<\/p>\n We used two SharePoint lists in the previous blog<\/a> to determine when a deployment finished and what changes were deployed as part of the deployment. The lists were:<\/p>\n We trigger our Flow when an item in the Current Deployments snapshot list is updated.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n \u00a0<\/p>\n Microsoft Flow\u2019s 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<\/a> and the VSTS REST API<\/a> makes it very easy to get one up very quickly.<\/p>\n 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 \u2013 we extract this object for use in subsequent actions by using a Compose action followed by a ParseJson action.<\/p>\n 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.<\/p>\n 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.<\/p>\n \u00a0<\/p>\n 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:<\/p>\n In the flow, once we get the change log information, we iterate over each change log record and push it into Power BI.<\/p>\n \u00a0<\/p>\n Now that we have looked at how the flow works, let\u2019s look at the different outputs of the flow. The first mail that gets sent out is the email notifying deployment to first release region \u2013 it looks as follows:<\/p>\n The next mail that gets generated is when deployment to all regions completes \u2013 this mail lists the regions where deployment finished along with deployment completion time and the changes that were deployed.<\/p>\n Finally, we can use the Power BI report to track which change was deployed to which regions.<\/p>\n \u00a0<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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. In this Flow of the Week, we’re developing an end-to-end deployment e-mail notification system and also generating Power BI-based change tracking report without writing a single line of code.<\/p>\n","protected":false},"author":362,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ms_queue_id":[],"ep_exclude_from_search":false,"_classifai_error":"","_classifai_text_to_speech_error":"","_alt_title":"","ms-ems-related-posts":[],"footnotes":""},"audience":[3378],"content-type":[],"job-role":[],"product":[3474],"property":[],"topic":[3421,3435],"coauthors":[2928],"class_list":["post-110864","post","type-post","status-publish","format-standard","hentry","audience-it-professional","product-power-automate","topic-application-modernization","topic-operations"],"yoast_head":"\n\n
Solution<\/h2>\n
\n
<\/p>\n
<\/p>\n
<\/p>\n
<\/p>\nGetting change logs in a build<\/h2>\n
<\/p>\n
<\/p>\n
<\/p>\nPushing change log to Power BI<\/h2>\n
<\/p>\n
<\/p>\nOutputs<\/h2>\n
<\/p>\n
<\/p>\n
<\/p>\nSummary<\/h2>\n