Prozessanpassungen in Visual Studio Team Services – die Basics

VSTSWährend der Prozess eines Team Projekts im klassischen Team Foundation Server beliebig angepasst werden konnte, waren solche Änderungen in den Visual Studio Team Services unmöglich. Doch nun hat Microsoft mit einem seiner letzten Updates die Grundlage geschaffen, Prozess-Anpassungen auch in der cloudbasierten ALM-Plattform durchzuführen.

Die Tatsache, dass Work Items und Workflows in Visual Studio Team Services, der in Azure gehosteten Variante des Team Foundation Servers, nicht angepasst werden konnte, hat viele Nutzer von einem Umstieg in die Cloud zurückgehalten. Doch dieser Hinderungsgrund scheint nun nach und nach zu verschwinden, da Microsofts Dienst zunehmend flexibler wird. Bereits im Dezember hat Microsoft einige Basisfunktionen veröffentlicht, um auch in VSTS umfangreiche Anpassungen vornehmen zu können.

Im ersten Schritt erlaubt uns Microsoft eigene Felder in ein existierendes Work Item hinzuzufügen und auch die Work Item-Maske zu individualisieren. Im Laufe der Zeit soll es dann auch möglich sein neue Work Item-Typen zu erstellen und auch typen-spezifische Workflows zu generieren.

Um diese Flexibilität zu gewährleisten, musste Microsoft einige Dinge beachten, die mit oberster Priorität behandelt wurden. So ist zum Einem  mit der festen Zuordnung Prozess-Template zu Team Projekt gebrochen worden. Nur durch die Verwaltung der Prozesse auf oberster Ebene und mit loser Kopplung zu den Team Projekten, kann solch ein Modell auf Dauer wart- und administrierbar bleiben.

Und zum anderen wurde sichergestellt, dass das System als solches auch nach Änderungen am Prozess aktualisierbar bleibt. Ich denke, dieses Problem kennen die meisten Nutzer, deren Prozess-Templates hochgradig individualisiert wurden.

Und zu guter Letzt entstand ein System, das einfach zu verstehen ist. Zurückgelassen wurden die Zeiten, in denen xml-Files umständlich angepasst werden mussten.

Justin Marks veranschaulichte die Vererbungsstrukturen des neuen Systems, im Vergleich zum alten, in einem seiner Blog-Post mit folgendem Bild:

Prozess Customization Hierarchy

Während im TFS jedes Team-Projekt ein konkretes Prozess-Template im Bauch hat, leiten die Projekte in VSTS immer nur von einer Prozessvorlage ab. Unabhängig davon, ob das eine Standardvorlage oder benutzerspezifische Vorlage ist.  Konkret bedeutet das: Änderungen an einem Prozess Templates werden automatisch von allen Team-Projekte übernommen, die dieses Template verwenden.

Create inherited process

Um nun einen Prozess zu individualisieren, muss eine Kopie von einem der drei Standard-Templates erzeugt werden. Nur innerhalb dieses abgeleiteten Templates können Anpassungen durchgeführt werden. Damit wird für Microsoft die eine entscheidende Voraussetzung erfüllt, dass eine Prozessaktualisierung durch ein System-Update gewährleistet bleibt.

Prozess Customization inherite

Change Team Project to use [template]

Der Clou ist nun, dass zwischen den abgeleiteten Prozess-Templates und dem Basis-Template umgeschaltet werden kann, sodass auch bereits existierende Team-Projekte einen angepassten Prozess verwenden können. Eine Konvertierung zu stammfremden Prozessen ist nicht möglich (z. B. von Agile zu Scrum).

Prozess Customization Change Process

Bekommt ein Team-Projekt ein abgeleitetes Template zugewiesen, werden z. B. neue Felder an der Oberfläche mit angezeigt und können verwendet werden. Wird von einem angepassten Prozess zurück zum Standard migriert, werden alle Custom Fields wieder ausgeblendet, da diese in der Basis nicht existieren. Deren Werte jedoch bleiben nach wie vor erhalten und werden auch in der Historie angezeigt.

Im nächsten Blog Post werde ich Euch zeigen, wie genau Ihr neue Felder in die Work Items einbauen könnt und was es dabei zu beachten gilt.

[1] https://blogs.msdn.microsoft.com/visualstudioalm/2015/12/10/adding-a-custom-field-to-a-work-item/
[2] https://msdn.microsoft.com/en-us/Library/vs/alm/Work/process/manage-process#Migrateateamproject