Azure DevOps & Power Automate: Wie Work-Items automatisch die Swimlane wechseln

Die Schritt-für-Schritt-Anleitung, wie Du mit Power Automate einen Flow zur automatischen Verschiebung von Work-Items anlegst.

•  Sebastian Mathys
•  16.11.2023
• DevOps

Auf dem Azure DevOps (ADO) Board visualisieren Swimlanes den Status von Arbeitspaketen (Work-Items) in mehreren Dimensionen. Leider bietet ADO noch keine native Möglichkeit, Regeln basierend auf den Swimlanes zu konfigurieren. In diesem Artikel zeigen wir Dir, wie Du mittels Power Automate Work-Items automatisch in eine Swimlane names Testing verschieben lassen kannst, wenn das Item entsprechend getaggt wurde. Wird das Tag entfernt, wandert das Item wieder in die Default-Swimlane. Das erspart Dir und Deinem Team manuelle Arbeit und hält Euer Board up-to-data.

Voraussetzungen

• Du brauchst eine Power Automate Premium License.

1) Flow und Trigger konfigurieren

Logge Dich in Power Automate ein und erstelle einen neuen Flow, indem Du My flows -> New flow klickst und Automated cloud flow wählst.

Im nächsten Fenster, wähle den Flow-Trigger When a work item is updated und klicke auf Create:

Das öffnet den Flow-Editor. Falls du das bisher noch nicht gemacht hast, musst du zunächst Power Automate in deinem Namen Zugang zu ADO gewähren (via OAUTH).

2) Trigger-Bedingung anpassen

Auf der Flow-Editor-Seite ist der Trigger ganz oben bereits als ein auswählbarer Block zu sehen. Wähle Deine ADO-Organisation als Organization Name und den für deinen Flow relevanten Project Name. Wenn du es gerne noch genauer haben möchtest, kannst du zusätzlich die Werte für Team Name, Area Path, Iteration Path etc. setzen.

Wähle dann Product Backlog Item als Type oder lasse das Feld leer, falls du den Flow unabhängig vom Ticket-Typ für jeden geänderten Work-Item triggern möchtest.

Um die Zahl der HTTP-Anfragen an ADO zu minimieren, solltest Du eine zusätzliche Bedingung direkt nach dem ersten Schritt einfügen, um zu prüfen, ob dein Work-Item dem gewünschten Typ entspricht - das ist aber nicht Inhalt dieses Artikels.

Klicke New step um fortzufahren.

3) Variablen konfigurieren

Einige Informationen des Work-Items, der den Flow triggert, müssen wir kurzzeitig speichern. Dies sind: Die aktuelle Swimlane des Items (in Power Autmate wird diese als Board Lane bezeichnet), die Tags, eine Platzhalter-Variable für die ADO-interne Swimlane-Referenz und allgemeine ADO-Projektinformation.

3.1) Die aktuelle Swimlane

Im Choose an operation Fenster, gebe variable ein und wähle unter Actions die Option Initialize variable.

Klicke auf die drei Punkte rechts vom neuen Variablenblock, wähle rename und gib einen möglichst sprechenden Bezeichner um den Flow übersichtlich zu halten. Du kannst auch eine Beschreibung hinzufügen, falls du diesen noch klarer machen möchtest.

In unserem Beispiel verwenden wir CurrentSwimLane als Name, aber du kannst jeden beliebigen Variablennamen verwenden. Als Type wähle String und unter Value, klicke auf Add dynamic content und wähle Board Lane aus.

Dies speichert die aktuelle Swimlane des triggernden Work-Items in der Variable CurrentSwimLane.

3.2) Tags

Füge einen weiteren initialize variable-Block mit Name = Tags, Type = String hinzu. Als Value, wähle Tags im Dynamic content aus.

3.3) Interne Swimlane-Referenz

Die Dynamic content-Variable Board Lane ist read-only und kann nicht geändert werden. Um die Swimlane eines Work-Items zu ändern, müssen wir deshalb einen kleinen Trick anwenden und eine interne Boardlane-Referenz verwenden, die für jedes Board eindeutig ist.

Füge eine Platzhalter-Variable im Flow ein, um die Referenz zu speichern. Füge dazu einen weiteren initialize variable-Block in unseren Flow ein und verwende Name = SwimLaneReference oder einen anderen passenden Namen, Type = String, und lasse den Value leer.

3.4) ADO project related variables

Man sollte nach Möglichkeit vermeiden, hardcodierte Werte in einer Flow-Logik zu verwenden. Initialisiere deshalb drei weitere Variablen, Org, Project and Team für deine ADO-Organisation, dein Projekt und dein Team. Diese kommen in den nächsten Schritten zum Einsatz, wenn wir mit der ADO-API interagieren.

4) Zustände prüfen

Um die Zahl der HTTP-Anfragen an die ADO-API zu reduzueren und um den Flow bestmöglich zu kontrollieren, wähle New step und füge eine Condition hinzu, welche alle ungenutzten Item-States der Swimlane exkludiert. In unserem Beispiel sind die Zustände New, Done und Removed nicht Teil der Swimlane-Konfiguration. Wähle State aus der Liste des Dynamic content, und füge deine Werte und weiteren Bedingungen mit Add -> Add row ein.

Jetzt sollte dein Flow in etwa so aussehen:

Die Bedingung erzeugt zwei Branches, If yes und If no. Den No-Branch können wir ignorieren, da der Flow für nicht passende Items nichts machen sollen. Wir konzentrieren uns also auf den Yes-Branch.

5) Board-interne Swimlane-Referenz

Wie oben beschrieben, ist es nicht möglich, die Swimlane-Variable eines Work-Items direkt zu ändern. Wir können sie aber durch einen API-Call abfragen, unter der folgenden URL:

1

https://dev.azure.com/<organisation>/<project>/<team name>/_apis/work/boards/<backlog level>

Der Wert von backlog level hängt von der Board-Kategorie ab, die für den Flow verwendet werden soll. Jedes backlog level, genau wie jedes Backlog items und Features hat seine eigenen Referenzwerte.

Du kannst die verschiedenen Levels herausfinden, indem du den Prozess für dein ADO-Projekt auswählst, in Organization Settings -> Boards -> Process unter Backlog levels, neben Work item types. Für Backlog items lautet die URL:

1

https://dev.azure.com/..../_apis/work/boards/Backlog%20items.

Achte auf korrektes URL-Encoding, falls das Level Leerzeichen beinhaltet. Die JSON-Antwort auf die HTTP-Anfrage enthält die Swimlane-Referenz unter fields -> rowField -> referenceName. Sie beginnt mit WEF.

Zurück zu unserem Power Automate Flow: Im If yes-Branch, klicke auf Add an action und suche nach Send an HTTP request to Azure DevOps. Wähle dann deine Org-Variable als Organization Name, dazu Method = GET und verwende die übrigen Variablen um die Relative URI im folgenden Format zu erzeugen:

1

<ADOproject>/<ADO team name>/_apis/work/boards/<backlog level>

Klicke wieder Add an action und suche nach Set variable. Nenne es SwimLaneReference und der Value sollte in etwa so aussehen:

1

outputs('Send_an_HTTP_request_to_Azure_DevOps_(get_reference)')?['body/fields/rowField/referenceName']

Send_an_HTTP_request_to_Azure_DevOps_(get_reference) ist dabei der Bezeichner dej HTTP-Anfrage aus dem vorigen Schritt. Beide Schritte zusammen sollten so aussehen:

6) Prüfe die Tag-Bedingung

Im letzten Schritt müssen noch Tag-basierte Bedigungen eingebaut werden. In unserem Beispiel haben wir zwei Swimlanes, Default and Testing und die folgenden beiden Anforderungen:

1. Befindet sich ein Work-Item in der Default-Swimlane und erhält das Tag Testing, soll es in die Testing-Swimlane verschoben werden.
2. Befindet sich ein Work-Item in der Testing-Swimlane und das Tag Testing wird entfernt, so soll es sich zurück in die Default-Swimlane verschieben.

Direkt unter unserem letzten Set variable-Block, klicke auf Add an action um eine weitere Bedingung hinzu zu fügen. Füge im ersten Feld der ersten Zeile der Bedingung den Dynamic Content Tags hinzu. Der Komparator sollte contains sein, da ein Ticket mehrere Tags haben kann. Das letzte Feld sollte Testing sein. Füge eine weitere Gruppe mit and und der Bedingung CurrentSwimLane is not equal to Testing hinzu. Dies erfüllt unsere erste Anforderung.

6.1) Tag hinzugefügt

Ist die Bedingung erfüllt, soll das Ticket in die Testing-Swimlane verschoben werden. Dies wird durch einen weiteren HTTP-Request an ADO veranlasst. In unserem neuen Yes-Branch, klicke auf Add an action und suche wieder nach Send an HTTP-request to Azure DevOps. Stelle den korrekten Organization Name ein und wähle PATCH als Method. Befülle die Relative URI im folgenden Format:

1

<ADOproject>/_apis/wit/workitems/@{triggerOutputs()?['body/id']}?api-version=7.0

Die Anfrage verwendet die ID des Work-Items, der unseren Flow getriggert hat als Dynamic content. Füge ein Headers-Feld mit dem Key Content-Type und dem Value application/json-patch+json hinzu. Der Body der Anfrage sollte im JSON format wiefolgt aussehen:

1
2
3
4
5
6
7

[
    {
        "op": "add",
        "path": "/fields/@{variables('SwimLaneReference')}",
        "value": "Testing"
    }
]

Der path für die Swimlane beinhaltet unsere SwimLaneReference-Variable und der value ist der Bezeichner der Swimlane, in welche der Item verschoben werden soll. Für weitere Details, siehe die ADO API- Dokumentation.

6.2) Tag entfernt

Als letztes müssen wir noch unsere zweite Anforderung berücksichtigen. Im If no-Branch, füge eine weitere Bedingung hinzu und prüfe die beiden folgenden, mit and verknüpften Statements:

• Tags does not contain Testing
• CurrentSwimLane is equal to Testing

Füge unterhalb der Bedingung, im neuen Yes-Branch, eine weitere HTTP-Anfrage hinzu. Diese ist ganz ähnlich aufgebaut, wie die andere, bis auf einen Unterschied: Der Wert im Body ist nun Default. Dadurch wird der Work-Item in die Default-Swimlane verschoben.

Damit sollte der letzte Teil unseres Flows wiefolgt aussehen:

Beachte, dass du, falls du eine kompliziertere Swimlane-Struktur hast, die Logik in unseren Bedingungen vermutlich anpassen musst.

Abschließende Bemerkungen

• Unser Beispiel zeigt ein Minimalsetup , ohne zusätzliche Checks, z.B. für die No-Branches oder ob überhaupt Swimlanes existieren. Denke daran, dass die Bedingungen Endlosschleifen triggern können, falls sie nicht richtig eingestellt sind.
• Einige Werte, wie States und SwimLanes sind in diesem Beispiel hartcodiert. Vergiss nicht, den Flow anzupassen, falls du etwas in deinem ADO-Board oder -Prozess änderst.
• Es kann zu Verzögerungen von bis zu 5 Minuten kommen, bis das Update eines Tickets den Power Automate Flow automatisch triggert.
• Falls du mehrere ineinander verschachtelte Bedingungen in deinem Flow verwendest, ist es besonders wichtig, auf deren korrekte Reihenfolge zu achten.

Nützliche Links

• Link zu Power Automate
• Link zur Azure DevOps API-Dokumentation