Einleitung
In einem Projekt zur Migration von Business Central 14 auf Version 25 eines Finanzdienstleisters aus der Leasing-und Factoringbranche befinden wir uns aktuell in der Phase der Smoke-Tests. Wir organisieren uns grundsätzlich in Azure DevOps (ADO) und erstellen für jede Unstimmigkeit ein (BUG) Work-Item, die im Rahmen der Smoke-Tests auffallen. Dieses wird anschließend durch die Entwicklung geprüft, idealerweise zeitnah gelöst und für einen Re-Test bereitgestellt.
Wie so oft gibt es auch Ausnahmen: Sollte sich herausstellen, dass es sich um einen sogenannten „Produkt-“ BUG handelt (d.h. ein Fehler in der Basis-Applikation), ist ein abweichender Prozess anzuwenden. In diesem Fall ist zunächst der Product Owner (PO), der für die Basis-Applikation zuständig ist, im jeweiligen Work-Item zu erwähnen und ein Approval (Zustimmung) einzuholen.
Nun man könnte an dieser Stelle kritisch hinterfragen, wieso es einer Erwähnung (Mention) im Kommentarbereich Bedarf und warum das Work-Item nicht direkt dem PO zugewiesen wird. Fairerweise muss erwähnt sein, dass jedes Team eine andere Vorgehensweise hat sich sich entsprechend organisiert. Wir müssen also das Vorgehen des anderen Teams respektieren.
Die Schritte für solch einen Prozess stichpunktartig zusammengefasst:
- Software-Tester/Consultant meldet Unstimmigkeit (Fehler) in Azure DevOps (ADO) an
- Entwicklung prüft den Fehler
- Bei einem BUG wird eventuell das Tag „PRODUCT“ im Work-Item durch die Entwicklung gesetzt
- Tester/Consultant ermittelt relevante Work-Items (mit TAG „Product“)
- Tester/Consultant holt sich das Approval per Erwähnung (Mention) im Kommentarbereich des Work-Items ein.
Die zwei letzten Schritte haben zur Folge, dass die Tester in unserem Team stets die Work-Items im Blick haben müssen und bei Bedarf aktiv die Bestätigung einholen müssen.
Diese manuelle Tätigkeit hat natürlich das Potenzial für eine Optimierung, denn wir möchten zum einen Fehler vermeiden (z.B. Vergessen sich mit dem PO abzustimmen) und zum anderen unsere Zeit und Ressourcen effizient nutzen.
Fangen wir an und erstellen zunächst eine User-Story samt Akzeptanzkriterien…
User-Story
Als professioneller Software-Tester möchte ich, dass der Product Owner (PO) automatisch im Kommentarbereich des Work-Items erwähnt wird. Dies soll geschehen, sobald ein bestimmtes Tag von den Softwareentwicklern gesetzt wird. Dadurch möchte ich eine schnelle Zustimmung (Approval) durch den Product Owner (PO) erreichen und manuelle Tätigkeiten reduzieren.
Akzeptanzkriterien
- Automatische Erwähnung
Der Product Owner (PO) als auch der Ersteller des Work-Items wird automatisch im Kommentarbereich des Work-Items erwähnt, sobald das definierte Tag „PRODUCT“ gesetzt wird. - Benachrichtigung
Der Product Owner (PO) und Ersteller des Work-Items erhält eine Benachrichtigung per E-Mail über die Erwähnung im Work-Item. - Reduzierung manueller Schritte
Der Prozess der Zustimmung erfolgt ohne manuelle Eingriffe durch den Software-Tester/Consultant.
Umsetzung/Lösung: Power Automate Flow
Wie der Titel des Blogeintrags bereits erahnen lässt, basiert unsere Lösung auf Power Automate von Microsoft. Bevor wir in die Details einsteigen, die relevanten Schritte kurz zusammengefasst:
- Trigger (Auslöser) ist die Aktualisierung des Work-Items, wenn es den Tag „PRODUCT“ enthält.
- Anschließend werden die vorhandenen Kommentare des Work-Items abgerufen und geprüft, ob bereits eine Erwähnung (Mention) für das Approval gibt.
- Falls ja, verlassen wir den Flow, da keine weiteren Aktivitäten notwendig sind.
- Wenn es jedoch noch kein Kommentar für das Approval gibt, ermitteln wir die ADO-User-ID (GUID) des Product Owners und des Work-Item-Erstellers. Zum Schluss erstellen wir einen Kommentar mit der Erwähnung des Product Owners (PO) und des Erstellers im Work-Item.
Los geht’s, schauen wir uns den Power Automate Flow etwas genauer an!
Trigger & Variablen
Auslöser für den Flow ist die Aktualisierung (Speichern) des Work-Items. Damit der Trigger nicht mit jedem Speichern eines Work-Items ausgeführt wird, schränken wir das Ganze ein. Wir prüfen zusätzlich, ob das Work-Item den Tag „PRODUCT“ enthält. Nur dann soll der Flow ausgeführt werden.
Dies erreichen wir, in dem wir in den Triggerbedingungen folgende Zeile hinzufügen:
@contains(triggerOutputs()?['body/fields']?['System_Tags'],'PRODUCT')Zusätzlich definieren wir zwei Variablen:
- In der Variable TextADOProductOwnerEmail ist die E-Mailadresse des PO definiert.
- In der Variable TextAzureDevOpsPAT ist der Personal Access Token (PAT) hinterlegt.
Hier ist zu beachten, dass aus Sicherheitsgründen der PAT nur die erforderlichen Berechtigungen zugewiesen bekommt.
Kommentare des Workitems abrufen und filtern
Als Nächstes rufen wir die Kommentare des Work-Items ab, welches den Trigger ausgelöst hat. Dies geschieht mit einer REST API Abfrage. Details zur Abfrage finden wir auf den Microsoft Learn Seiten: Comments – Get Comment – REST API (Azure DevOps Work Item Tracking) | Microsoft Learn
Im Weiteren filtern wir die Kommentare des Work-Items und prüfen, ob ein bestimmtes Signalwort vorkommt. In unserem Fall ist es das Hashtag „#POApproval“. Nur wenn kein Hashtag mit „#POApproval“ ermittelt werden kann, soll ein Kommentar mit einer Erwähnung erstellt werden. Falls es bereits ein Kommentar mit #POApproval gibt, gehen wir davon aus, dass das Approval bereits beantragt wurde und verlassen den Flow.
Power Automate Flow – Kommentare des Workitems abrufen und filtern
Azure DevOps Benutzer abrufen, filtern und GUID ermitteln
Mit der Bedingung prüfen wir, ob es es bereits ein Kommentar mit dem Hashtag „POApproval“ gibt. Falls nicht, rufen per API die Azure DevOps Benutzer ab und filtern nach der E-Mailadresse des PO (Product Owners). Die Emailadresse hatten wir zu Beginn in der Variable TextADOProductOwnerEmail festgelegt. Für die Abfrage verwenden wir Users – List – REST API (Azure DevOps Graph) | Microsoft Learn
Für die Erwähnung im Kommentar benötigen GUID des Benutzers in Azure DevOps (nicht zu verwechseln mit der Office 365 GUID). Diese können wir über die sogenannte storageKeyURL abrufen. Diese wird uns über die User list Abfrage bereitgestellt. Weitere Details finden wir in Storage Keys – Get – REST API (Azure DevOps Graph) | Microsoft Learn
Auch für den Workitem-Ersteller benötigen wir die GUID. Hier ist unsere Vorgehensweise ähnlich wie zu vor. Wir rufen die E-Mailadresse des Erstellers ab, anschließend die storageKeyURL ab und zum Schluss ermitteln wir daraus die GUID.
Azure DevOps Kommentar mit Mention (Erwähnung) erstellen
Im letzten Schritt erstellen wir einen Kommentar mit der Erwähnung des ProductOwners und des Work-Item-Erstellers. Auch hierfür verwenden wir die REST API von ADO: Comments – Add – REST API (Azure DevOps Work Item Tracking) | Microsoft Learn
Für die Erwähnung im Kommentar benötigen wir die User-ID (GUID des jeweiligen ADO Benutzer) und ein bestimmtes Attribut „data-vss-mention“. Details dazu finden wir wie so oft auf den Microsoft Learn Seiten: Verwenden von @mentions in Arbeitselementen und Pull Requests – Azure DevOps | Microsoft Learn
Für unseren Anwendungsfall müssen wir darauf achten, dass wir die „“ (Anführungszeichen) noch „escapen“. D.h. wir verwenden statt “ die Zeichensequenz \“ – siehe Screenshot
Vollständiger Power Automate Flow
Hier ist der gesamte Flow zusammengefasst:
- Trigger: Aktualisierung eines Work-Items mit dem Tag „PRODUCT“.
- Prüfen: Existenz eines Kommentars mit „#POApproval“.
- Ermittlung der Azure DevOps GUIDs: Für PO und Work-Item-Ersteller.
- Azure DevOps Kommentar erstellen: Automatische Erwähnung (Mention).
Ergebnis
Die Lösung erfüllt alle Anforderungen: Sobald das Tag „PRODUCT“ gesetzt wird, erstellt der Flow automatisch einen Kommentar mit Erwähnungen. Beide Parteien erhalten eine E-Mail-Benachrichtigung. Manuelle Schritte entfallen und der Prozess wird effizienter.
Glossar
| Begriff | Abkürzung | Beschreibung |
| Smoke-Test | Smoke-Tests sind oberflächliche Prüfungen, die als erste Qualitätskontrolle nach einer Softwareanpassung dienen. Sie zielen darauf ab, schnell grundlegende Funktionalitäten zu verifizieren und schwerwiegende Probleme frühzeitig zu erkennen. | |
| Azure DevOps | ADO | Azure DevOps ist eine Plattform von Microsoft, die Tools für die Softwareentwicklung zur Verfügung stellt. Sie unterstützt agile Praktiken und ermöglicht es Teams, effizient zusammenzuarbeiten. Azure DevOps Services | Microsoft Azure |
| Product Owner | PO | Der Product Owner (PO) ist eine Schlüsselrolle im agilen Softwareentwicklungsteam. Er kümmert sich unter anderem um die Erstellung, Priorisierung und Pflege des Product Backlogs (priorisierte Liste von Aufgaben und Anforderungen) |
| Globally Unique Identifier | GUID | Eine GUID (Globally Unique Identifier) ist eine 128-Bit-Zahl, die weltweit eindeutig ist. Sie wird oft genutzt, um Objekte in Software eindeutig zu identifizieren, z. B. Datenbankeinträge, Dateien oder Geräte. Ein typisches GUID-Format sieht so aus: 550e8400-e29b-41d4-a716-446655440000. Dank ihrer Einzigartigkeit lassen sich Konflikte bei der Identifikation vermeiden. |
| (Software) Migration | Eine Software-Migration bezeichnet den Prozess der Übertragung von Software, Daten oder Anwendungen von einem System, einer Plattform oder einer Umgebung in eine andere. | |
| Approval | Ein Approval in der Softwareentwicklung, insbesondere im Kontext von DevOps, bezeichnet den Genehmigungsprozess, bei dem eine vorgeschlagene Änderung, ein Update oder ein Deployment vor der Implementierung oder Bereitstellung überprüft und freigegeben wird. Approvals dienen dazu, die Qualität, Sicherheit und Stabilität von Softwareänderungen sicherzustellen. | |
| Work-Item | Ein Work-Item in der Softwareentwicklung ist ein Arbeitselement, das eine Aufgabe, Anforderung, Fehler, Verbesserung oder ein anderes Element beschreibt. Work-Items werden verwendet, um Arbeit zu planen, zu organisieren, nachzuverfolgen und zu verwalten, und sind ein zentraler Bestandteil von agilen Frameworks wie Scrum. |
