1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Implementing Continuous Feedback with Azure DevOps

Error Feedback

Contents

keyboard_tab
Intro & Feedback Overview
1
Course Introduction
PREVIEW1m 11s
2
What is Feedback?
PREVIEW1m 39s
Feedback Loops & App Center Analytics
Baselines & Noise
Course Summary
15
Summary
3m 49s

The course is part of this learning path

AZ-400 Exam Prep: Microsoft Azure DevOps Solutions
course-steps 11 lab-steps 5 description 1
play-arrow
Start course
Overview
DifficultyIntermediate
Duration49m
Students93
Ratings
5/5
star star star star star

Description

The application lifecycle doesn’t finish with app deployment. Feedback is an important element of refining an application, whether that’s exception detection and diagnoses or improving the user experience. In this course, we will look at a suite of services that capture a vast array of feedback data, ranging from exceptions to client and server telemetry. This data can be turned into easily digestible information that can be used to trigger alerts and feedback into the development lifecycle as work items.

This course begins by describing what feedback is, and the types of feedback for improving application performance and usability. It then moves on to how we can integrate feedback into the software development lifecycle and what tools we can use to simplify that task. Finally, we will look at optimizing feedback mechanisms to get meaningful data from feedback noise.

For any feedback and questions relating to this course, please contact us at support@cloudacademy.com.

Learning Objectives

  • Designing application and user feedback loops
  • Setting up crash and event notifications for App Center
  • Setting up work item integration from App Center 
  • Making sense of App Center’s analytic and diagnostic information
  • Adding Application Insights Telemetry to an application
  • Setting up Application Insights alerts
  • Work item integration from Application Insights
  • Designing feedback dashboards
  • Viewing Application Insights Telemetry data
  • Discussing types of user feedback and how they can be captured
  • Ways to baseline and filter feedback data

Intended Audience

This course is intended for:

  • People preparing for Microsoft’s AZ-400 exam
  • App developers
  • Project managers

Prerequisites

To get the most from this course, you should have some experience with Microsoft Azure and application development, as well as knowledge of software project management concepts.

Transcript

Let’s start with something we are all familiar with, exceptions, errors and crashes. I think it’s fair to say that making your app bug, or at least crash free would be the number one priority. Not to state the obvious, but its very bad manners to have your app crash with an unhandled exception. While on the face of it, exception handling may seem binary – the app had an exception or it didn’t, this is not how it goes. I’m sure most of you are aware of the undocumented feature meme, making fun of an application’s unexpected behavior. This type of error or misbehavior is subtle, and its capture is accordingly more complex so I will tackle it after addressing crashes and exceptions.

At the very least your app should have some general exception handler to allow it to exit gracefully. While not crashing out, exiting with some generic error message isn’t much better and will leave users frustrated. Like any product, if it breaks people won’t buy it. If you are developing for an enterprise environment where staff are forced to use your app, users will bad mouth it and it will take some time to regain their trust even when the bugs are fixed. Most, as in 99.9% of users will not report a bug with any kind of useful information about what function they were performing at the time and the application state at the time, assuming that they could. In an ideal world we would have tested the app and it would be deployed bug free. As this almost never happens the next best thing, is that we, the developers are informed of these exception situations with relevant application state data so that they can be addressed and remedied as quickly as possible.

If we were going to design an error feedback, or bug tracking solution from scratch what would it look like? This solution needs to work on 2 levels. From a project perspective there needs to be a bird’s eye view of the current state, global reporting and monitoring at a glance. Enter the project dashboard. We need to easily see the number of outstanding issues, work in progress and completed tickets. What bugs those issues relate to, and where those issues are in relation to resolution. A good comprehension of the current state of play allows for effective project management in terms of directing resources to where they are most needed. Without this information any predictions in delivery times range from less than optimal to arbitrary. The other level a bug tracking solution works at is ticket level, managing and monitoring individual issues. We need to capture the bug with as much diagnostic information as possible. Then enter the bug into a workflow. This should involve an initial categorization, which at a bare minimum, should discriminate between crashes and non-fatal errors using a priority rating. Then there should be the ability to assign the bug to a development resource, with that resource updating the current status of the bug and the resolution process. Once the bug issue has been resolved or fixed, then the bug status can be set to closed.

 

For a start we would need to capture the exception in the application. This would involve recording the location of the exception, like the function and library, perhaps with the input parameters. Ideally you would want to know what operating system and version the app was running on, and even the device. Once the critical data has been collected it needs to be transmitted to an error log external to the application. Once the error data has been received it would be nice if it was automatically classified and prioritized. For example, an exception that caused the app to crash would be marked as critical, while a null object exception that was caught, handled and not visible to the user maybe giving a lower priority. The exception priority will influence whether a special release is urgently needed, or the fix can be incorporated into the next planned release. The fix is implemented, and the new release is deployed, closing the feedback loop.

 

About the Author

Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a  Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.