Personalized Community is here!
Quickly customize your community to find the content you seek.
Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2021 Release Wave 1Discover the latest updates and new features to Dynamics 365 planned April 2021 through September 2021.
Release overview guides and videos Release Plan | Preview 2021 Release Wave 1 Timeline
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
DevOps has become more and more ingrained into our Power Platform project lifecycle. Work item tracking and feedback tools for teamwork. Continuous integration and delivery for code changes and solution deployments. Automated testing for assurance, compliance and governance considerations. Microsoft's tool, Azure DevOps provides native capabilities to plan, work, collaborate and deliver. Each step along the way in our Power Platform DevOps journey can be tracked and monitored which will be the primary objective of this article.
In this article, we will focus on integrating Azure DevOps with Microsoft Teams to help coordinate and collaborate during a deployment. We will explore the various bots and how to set them up. From there we will walk through a sample scenario involving multiple teams working together. Finally, we will look to automate release notes using web hooks and Azure Function.
Sources of Azure DevOps events that impact our delivery can come from virtually any area of the platform including work items, pipelines, source control, testing and artifact delivery. For each one of these events, such as completed work items, we can setup visualizations such as charts based on defined queries. Service hooks and notification subscriptions can be configured to allow real time reporting of events to external parties and systems allowing for us to stay in a state of continuous communication and collaboration.
AUTHOR NOTE: Click on each image to enlarge for detail.
Azure DevOps bots with Microsoft Teams has quickly grown into one of my favorite features. For instance, Azure DevOps dashboards and kanban boards can be added to channels for visualizations of progress as shown below.
Multiple Azure DevOps bots can be configured to deliver messages to and from Microsoft Teams to allow for continuous collaboration across multiple teams and channels. These bots can work with Azure Pipelines, work items and code pull requests.
For monitoring and orchestrating deployments across our various teams, the Azure Pipelines bot is essential. Let's begin by setting up subscriptions to monitor a release pipeline.
NOTE: The rest of this document will be using a release pipeline as an example, but this will also work with multi-stage build pipelines that utilize environments.
Use the "subscriptions" keyword with the Azure Pipelines bot to review and modify existing subscriptions and add new ones.
In the above example, we are subscribing to any changes in stages or approvals for a specific release pipeline. Its recommend to filter to a specific pipeline to reduce clutter in our Teams messaging. The Azure Pipeline bot, using actions described in the article "Azure DevOps - Notifications and Service Hooks", can be further filtered by build statuses. This is helpful to isolate the messages delivered to a specific Teams channel.
Once configured, as soon as our pipeline begins to run, Microsoft Teams will begin to receive messages. Below is an example showing the deployment of a specific release including stages and approval requests. What I find nice about this is that Microsoft Teams works on both my mobile devices and even Linux based operating systems, allowing any team on any workload to utilize this approach.
I also want to point out that Azure DevOps also has the ability to natively integrate with other 3rd party tools such as Slack (Similar to the Teams bots), ServiceNow and Jenkins.
Deployments within a release pipeline allow for numerous ways to integrate monitoring into Azure DevOps processes. Each deployment include pre and post conditions which can be leveraged to send events and metrics. For instance, the Azure Function gate can be used to invoke a micro service that writes to Azure Application Insights, creates ServiceNow tickets or even Kafka events. The possibilities are endless, imagine sending messages back to the Power Platform for each stage of a deployment!
Pre and Post approvals can be added to each job in the release pipeline. Adding these can assist during a complex deployment requiring coordination between multiple teams dispersed geographically. Shown below is a hypothetical setup of multiple teams each with specific deliverables as part of a release.
In this scenario, a core solution needs to be deployed and installed before relying features can begin. When any of the steps in the delivery process begins, the originating team needs to be notified in case of any issues that come up.
Using approvals allows the lead of the specific feature team to align the resources and communicate to the broader team that the process can move forward. The full example can be found below.
Here is an example of an approval within Microsoft Teams, notifying the lead of the core solution team that the import process is ready. The approval request shows the build artifacts (e.g. solutions, code files, etc), the branch and pipeline information.
At the heart of a gated deployment approach is the ability to search for inconsistencies or negative signals to minimize unwanted impact further in the process. These gates, which can be set to run before or after a deployment job, allow us to query for potential issues and alerts. They also could be used to notify or perform an operation on an external system.
Deployment gates provide the ability to run queries on work items within your Azure DevOps project. For instance this allows release coordinators and deployment managers to check for bugs reported from automated testing using RSAT for Dynamics 365 F&O or EasyRepro for Dynamics 365 CE. These queries are created within the Work Items area of Azure DevOps. From there they are referenced within the pipeline and based on the data returned, upper and lower thresholds can be set. If these thresholds are crossed, the gate condition is not successful and the process will halt until corrections are made.
As mentioned above Azure Function is natively integrated within deployment gates for Release Pipelines. These can be used for both a pre condition and post condition to report or integrate with external systems.
Deployment gates can also invoke REST API endpoints. This could be used within the Power Platform to query the CDS API or run Power Automate flows. An example could be to query the Common Data Service for running asynchronous jobs, creating activities within a Dynamics 365 environment or admin actions such as enabling Admin mode. Another could be to use the robust approval process built in Power Automate for pre and post approvals outside of the Azure DevOps licensed user base.
In the previous section I described how to introduce quality gates to a release securing each stage of the pipeline. Release pipelines are useful to help control and coordinate deployments. That said, environments and build pipelines allow for use of YAML templates which are flexible across both Azure DevOps and GitHub and allow for teams to treat pipelines like other source code.
Environments in Azure DevOps allow for targeted deployment of artifacts to a collection of resources. In the case of the Power Platform, this can be thought of a release to an Power Platform environment. The use of pipeline environments is optional, that is unless you begin work using Release pipelines which do require environments. Two of the main advantages of environments are deployment history and security and permissions.
Environment security checks, as mentioned above, can provide quality gates similar to the current capabilities of Release Pipelines. Below is an example of the current options compared to Release Pre and Post Deployment Quality Gates.
Here is an example of linking to a template in GitHub.
Compare this to the Release Pipeline Pre or Post Deployment Quality Gates.
In the above example, we have a multi-stage release pipeline that encompasses multiple teams from development to support to testing. The pipeline relies on multiple artifacts and code branches for importing and testing.
In this example, we have a core solution containing Dynamics 365 entity changes that are needed by integrations. They will need to lead the deployment and test and notify the subsequent teams that everything has passed and can move on.
Below is an example of coordination between the deployment team and the Core team lead.
Below is an image showing the entire release deployment with stages completed.
The Azure Application Insights Release Annotations task is a marketplace extension from Microsoft allowing a release pipeline to signal an event in a release pipeline. An event could be the start of the pipeline, the end, or any event we are interested in. From here we can use native functionality of Azure Application Insights to stream metrics and logs.
Service Hooks are a great way of staying informed of events happening within Azure DevOps allowing you to be freed up to focus on other things. Examples include pushing notifications to your teams' mobile devices, notifying team members on Microsoft Teams or even invoking Microsoft Power Automate flows.
The sample code for generating Azure DevOps release notes using an Azure Function can be found here.
In this article we have worked with Azure DevOps and Microsoft Teams to show an scenario to collaborate on a deployment. Using the SDK or REST API, Azure DevOps can be explored in detail, allowing us to reimagine how we consume and work with the service. This will help with automating release notes and inviting feedback from stakeholders.
Previously we looked at setting up notifications and web hooks to popular services. We then reviewed the Azure DevOps REST API to better understand build pipelines and environments.
If you are interested in learning more about specialized guidance and training for monitoring or other areas of the Power Platform, which includes a monitoring workshop, please contact your Technical Account Manager or Microsoft representative for further details.
Your feedback is extremely valuable so please leave a comment below and I'll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, please go here to submit a new issue.
Monitoring the Power Platform: Introduction and Index
Business Applications communities