A Citizen Developer using Azure Boards in an Agile Process I hear you cry, why? When I was first introduced to DevOps I will be the first to admit I hated the process. Working with Developers who asked if I had pushed my latest build to Git, unfamiliar terminologies, the list was endless. However, over time I began to appreciate the process and discovered that it actually focused my solutions to what was needed rather than what I thought was needed.
In this article, I'll show you how to collect failures in your deployed Power Automations and produce a Bug Backlog linked to your Solution Features within Azure Boards.
Here is an example of a typical Kanban board that I have set for my current Project. I have it broken in to an Epic which is the ultimate goal of the Project, a User Story, in this instance the HR Manager and, a number of Features the HR Manager would like to be implemented.
Azure Boards and Webhooks in Microsoft Teams
So now I have my Project Scope and Goals defined, I have created a Microsoft Team. In the General Channel I'm going to Add a Tab.
Select the Azure DevOps App and configure it accordingly to the Organization and Project as well as Team and Backlog level you wish to display. I am choosing Kanban Board as my display but, you could also as easily add a Dashboard if you have it configured.
I have also added an additional Channel called Bug Backlog. On the channel settings, I have added the Azure DevOps Connector and configured it to display new Work Items of type Bug.
You can have more than one of these connectors configured whereby, you could have notifications for both Created and Updated items. Alternatively, you may have different channels configured for all Work Item types.
Having the Channel and Connection setup will now enable notifications from Azure DevOps to my Team that there have been Bugs logged which, remove the need to add a notification step in my Power Automation.
Building the Power Automation
I'm going to add the additional actions to log any Bugs to the Automation I created in my previous https://www.365bi.ca/post/produce-business-documentation
I need to add 5 additional Initialize Variable actions to the existing Automation. These will be used within the Automation for getting the current Automation Run, identifying the Feature within Azure DevOps and logging any errors that occur during an automation run.
Name: Automation Environment
Type: String
Value: Copy the URL of your Automation and remove everything after "environments/"
Name: Feature Work Item ID
Type: Integer
Value: Get the Work Item ID from Azure Boards of the Feature you are logging bugs to.
Name: Assigned To
Type: String
Value: You can't query the Team Members in Azure DevOps so if you want to automatically assign a user to the Bug you will need to construct this as Display Name <email address> of the Team Member
Name: Errors Array
Type: Array
Now we have added our additional Initialize Variable actions we need to identify within our existing Automation where the likely failure points are going to be. You could capture any errors generated from any action however, you will end up having a very complex Configure run after scope which could actually fail the automation even though none of the actions do.
Looking at the Automation, the highest likelihood of errors being generated are the Get manager action, Create DOCX file action and the Create PDF file action. These are the areas where I am going to add additional Actions and set my Configure run after.
We are now going to add an Append to Array Action to capture any Get Manager Errors.
Name: Errors Array
URL : Select the Expressions Tab rather than Dynamic Content to build the expression. You may need to change the Output Names dependent on what you called your Actions.
outputs('Get_manager_(V2)')This action also requires to have its "Configure run after" set. Select "Has failed " and click done.
Next I need to set the 'Configure run after' on the Generate Employee Status Notice Scope. Within this Automation, I'm not using notifications actions that require the Manager Email address so I don't need to fail the whole automation. In this instance, I can set the run after to "is successful" and "is skipped ". If the requirement for notifications is requested later, I would change this to "is skipped " only.
We are now going to add an Append to Array Action to capture any Create DOCX fie Errors.
Name: Errors Array
URL : Select the Expressions Tab rather than Dynamic Content to build the expression. You may need to change the Output Names dependent on what you called your Actions.
Outputs('Create_DOCX_file')This action also requires to have its "Configure run after" set. Select "Has failed " and click done.
Next I need to set the 'Configure run after' on the Update DOCX File Properties. I set the run after to "is skipped" which, will ensure the action only runs if the Append to Error Array is not triggered. The two Actions below do not need changed as they only run if the previous action "is successful".
We are now going to add an Append to Array Action to capture any Create PDF fie Errors.
Name: Errors Array
URL : Select the Expressions Tab rather than Dynamic Content to build the expression. You may need to change the Output Names dependent on what you called your Actions.
outputs('Create_PDF_file')This action also requires to have its "Configure run after" set. Select "Has failed " and click done.
I now need to add a Switch Action to handle the Update PDF file properties action and, to add the additional actions to write any errors captured to the Azure Board. If I set the 'Configure run after' on the Update PDF File Properties to "is skipped" this action would run if the Create DOCX fie had error as, all preceding actions would have been skipped.
In the "On" clause select the Expressions Tab rather than Dynamic Content to build the expression. You may need to change the Output Names dependent on what you called your Actions.
length(variables('Errors Array'))Set the Case Equals to 0. This will enable the final action to run if there has been no errors in the previous actions. The Default clause will be used for our additional actions to create our Bugs within Azure Boards. Set the 'Configure run after' on the Switch if Automation has Errors to "is successful" and "is skipped".
I now have all the 'Configure run after' scopes configured and, you can clearly see which actions are affected by the differences in the Process Flow Arrows. We are now able to add our additional actions to create Bugs within Azure Boards linked as a child relationship to our Feature Work Item.
We are going to work on the righthand side of the Switch Action now (Default). We are going to add three Compose actions, Azure DevOps Get Work Item Details action and a Azure DevOps Create Work Item action. The Azure DevOps actions are Premium Actions and you may require an additional subscription. We are now going to set the fields in the Actions that we have added. Set the fields
Compose Action (Compose Automation Instance)
Input: Select the Expressions Tab rather than Dynamic Content to build the expression. You may need to change the Output Names dependent on what you called your Actions.
workflow()Compose Action (Compose Repo Step)
Input: Select the Expressions Tab rather than Dynamic Content to build the expression. You may need to change the Output Names dependent on what you called your Actions.
concat(variables('Automation Environment'),variables('Automation')?['tags']['environmentName'],'/flows/',variables('Automation')?['name'],'/runs/',variables('Automation')?['run']['name'])Compose Action (Compose Errors Array to Text)
Input: Errors Array variable
Get Work Item Details
Organization Name: Select as Appropriate
Project Name: Select as Appropriate
Work Item Type: Feature
Work Item ID: Feature Work Item ID variable
Create a Work Item
Organization Name: Select as Appropriate
Project Name: Select as Appropriate
Work Item Type: Bug
Title: As desired
Description: Compose Errors Array to Text output
Priority: As desired
Iteration Path: select from Get work item details
Area Path: select from Get work item details
Link URL: select URL from Get work item details
Assigned To: Assigned To variable
Repo Steps: <a href="Compose Repo Step output">View Automation Instance causing error</a>
State: As desired
Tags: As desired
Lets save the Automation and Test it.
MS Team Notification
So I have run my Automation and it had a failure. The new Bug Work Item was added to my Kanban Board, linked to the Feature Work Item and notifications were triggered from my Team Channel without the need to add an additional Action within my automation.
When I view the Bug Work Item in Azure Boards, I can quickly see the details on the failure as well as having a hyperlink within the Repo Step to directly open the Automation Instance.
Some Final Thoughts
I use this method to track Bugs when I have made an Automation available to other Users for testing. However, I have now started to retain this functionality even after testing has been completed and the Automation has been made available to all users. Inevitably, you will never manage to catch all testing scenarios and, there are occasions when service disruption may affect your Automations and this becomes a very easily methodology of resubmitting the Automation on service resumption.
Now not everyone is going to be using Azure Boards for their Development but, the functionality of recording bugs within your Automation can be done within the Issue Tracking Template in the Lists Feature of Office 365.
I would highly recommend if you want to explore this option, you take a look at Norm Young's Blog Post which will guide you through setting up your Issue Tracker https://normyoung.ca/2020/08/07/microsoft-lists-a-closer-look-at-the-issue-tracker-template/