Den Workflow oder einzelne Prozessschritte in der Softwareentwicklung anzupassen, sind mit dem Team Foundation Server relativ leicht möglich. Man muss nur das Process Template anpassen und hat im Handumdrehen ein neues Feld zum Task hinzugefügt oder andere kleine Erweiterungen gemacht. Dabei wird der Nutzer auch durch verschiedene Tools, wie z.B. den Team Foundation Server Power Tools sehr gut unterstützt. Doch wie bewahrt man das Process Template vor unnötigen Anpassungen und wie sieht es eigentlich mit der Versionierung dieser Änderungen aus? Woher weiß man, welchem Team Project im TFS welches Process Template in welcher Version des Process Templates zugrunde liegt?
Oberstes Gebot bei der Bearbeitung von Process Templates ist die Verwendung der Versionskontrolle. Bevor man eine Anpassung macht, sollte man den Source Code eines Process Templates zunächst in seiner noch unveränderten Form in einem TFS Repository einchecken. Dies ermöglicht die Vorteile einer versionssicheren Dateiablage zu nutzen, um später Änderungen besser nachvollziehen oder Stände miteinander vergleichen zu können. Wenn man häufig Anpassungen der Art macht, dann ergibt sich in der Versionskontrolle in regelrechtes Sammelsurium an Process Templates (siehe Abbildung 1).
Damit hat man einen sehr wichtigen Grundstein für die Weiterentwicklung gelegt, auf dem man stabil und verlässlich weiter an seinem Template arbeiten kann. Dies ist jedoch nur der erste Schritt. Direkt als nächstes ist es wichtig, ein haltbares Versionierungsschema zu implementieren.
Nachdem ein neues Team Project auf Basis eines bestimmten Process Templates im Team Foundation Server erstellt wurde, kann man nämlich nicht mehr so einfach herausfinden, welches Process Template beim Anlegen des Team Projects verwendet wurde. Mit der Version 2012 des Team Foundation Servers hat Microsoft hier nachgebessert. Die Datei Classification.xml des Process Templates ist in der Lage eigene Properties aufzunehmen.
Genau dieses Feature (übrigens auch schon in TFS 2010 verfügbar) hat Microsoft nun erstmals selbst genutzt, um ein Property namens “Process Template” einzufügen (siehe dazu Abbildung 2). In dem Screenshot ist die Datei Classification.xml des von Microsoft ausgelieferten Process Templates Microsoft Visual Studio Scrum 2.2 zu sehen. Die in Zeile 25 beginnende Sektion properties gab es bereits vor dem Team Foundation Server 2012. Nun hat Microsoft diese jedoch selbst genutzt, um Versionsinformationen zu hinterlegen. Diese werden beim Erstellen eines neuen Team Projects mit in der TFS Datenbank gespeichert und sind somit später abrufbar (später mehr dazu).
An dieser Stelle kann man nun ansetzen und auf die gleiche Weise weitere Eigenschaften bekanntmachen. Zwei zusätzliche Informationen, die sich als nützlich erwiesen haben, sind die Versionsnummer, unter der das Template initial verwendet wurde sowie ein Verweis auf das Process Template, welches als Basis für die eigene Weiterentwicklung gedient hat. Die konkrete Vergabe der Versionsnummer kann natürlich frei gewählt werden. In dem hier gezeigten Beispiel ist das AIT-Versionsnummernschema zum Einsatz gekommen. Ein möglicher Aufbau der Datei Classification.xml nach diesem Schema ist in Abbildung 3 dargestellt.
Wie bereits angekündigt, ist es ein Leichtes, diese Informationen wieder aus einem existierenden Team Project auszulesen. Dafür gibt es verschiedene Möglichkeiten. Man kann sich z.B. ein kleines Tool schreiben, welches über die TFS API diese Informationen zur Verfügung stellt. Eine Alternative ohne die TFS API ist der Zugriff auf die TFS Datenbank mit einem einfachen Select-Statement.
SELECT [tbl_projects].[project_id]
, [tbl_projects].[project_name]
, [tbl_project_properties].[name]
, [tbl_project_properties].[value]
FROM [tbl_projects]
INNER JOIN [tbl_project_properties]
ON [tbl_projects].[project_id] = [tbl_project_properties].project_id
WHERE [tbl_projects].[project_name] like 'AIT.Scrum%'
Diese Abfrage kann einfach wiederverwendet werden. Man muss lediglich den Namen des Team Projects in der Where-Clause austauschen. Abbildung 4 zeigt das Ergebnis der Abfrage.
Die Process Templates, die mit dem TFS 2012 ausgeliefert werden, enthalten noch eine weitere Neuerung bzgl. der Versionierung. In der Root Process Template Datei ProcessTemplate.xml gibt es bei den Metadaten des Templates (XML-Tag metadata) das neue version-XML-Tag (siehe Abbildung 5). Dort erhält das Process Template einen eindeutigen Identifier sowie eine interne, zweigeteilte Versionsnummer in Form eines Major- und Minorteils.
Diese Daten tauchen im Bereich der Process Templates auch in der TFS Datenbank wieder auf. Man kann diese Informationen nutzen, um die Version eines Process Templates im Process Template Store, also noch bevor ein Team Project erzeugt worden ist, genauer zu beschreiben.
Nachdem der Quellcode des Process Templates nun unter vollständiger Kontrolle der Quellcodeverwaltung ist und das Process Template auch noch ein paar Versionsinformationen erhalten hat, kann man den nächsten Schritt in der Weiterentwicklung erschließen: Branch-Struktur der Process Templates.
Die Tatsache, dass der Source Code durch die vorher beschriebenen Schritte sowieso im Source Control des TFS verfügbar ist, kann nun noch durch Verwendung von Branches ausgenutzt werden. Das Elternelement eines Branch-Baums ist dabei stets das vom Hersteller ausgelieferte Process Template. In dem Beispiel des Scrum Templates von Microsoft ist Microsoft Visual Studio Scrum 2.2 also das Wurzelelement eines Branch-Baums (siehe Abbildung 6).
In dem in der Abbildung dargestellten Beispiel gibt es im Unternehmen zwei verschiedene Business Units, die für die Entwicklung verschiedener Produktlinien verantwortlich sind. Dabei verwenden sie unterschiedliche Prozesse, was den Einsatz verschiedener Process Templates im TFS nach sich zieht. Die Entwicklung der beiden Produktlinien B.I und B.II ist bzgl. der Zustände der einzelnen Work Items jedoch gleich. Sie unterscheiden sich nur auf Feldebene der einzelnen Work Item Typen. Deshalb ist es sinnvoll, für diese Process Templates noch einmal einen gemeinsamen Knoten in der Branch-Hierarchie abzubilden, hier: Business Unit B.
In der Praxis hat sich gezeigt, dass es nur schwer möglich ist, Anpassungen, die innerhalb eines Process Templates entstanden sind, z.B. bei Product Line B.II, durch Reverse Integration auf andere Zweige zu verteilen. Jedoch dokumentiert die Branch-Struktur hervorragend die Entstehung sowie die Beziehungen der einzelnen Anpassungen. Außerdem kann man Änderungen allgemeiner Art relativ gut durch Forward Integration verteilen.
Hierbei ist es wie in der Softwareentwicklung entscheidend, dass die Branch-Hierarchie sorgfältig definiert wurde. In dem Beispiel aus Abbildung 5 ist es durchaus denkbar, zwischen dem Wurzelknoten und den beiden Business Units noch einen gemeinsamen Zwischenknoten einzufügen, um Änderungen, die für alle Templates zutreffen, an einer Stelle implementieren zu können. Ein Beispiel dafür kann ein Feld sein, welches in einem bestimmten Work Item Type (z.B. Task) in allen Templates vorhanden sein soll.
Wenn man diese Forward Integration zum Verteilen von Neuerungen weiter durchdenkt, kommt man noch zu einem weiteren Knackpunkt: die Formatierung des XML-Codes. Wenn man Process Template Anpassungen im großen Stil macht, kann es sinnvoll sein, sich auf bestimmte Richtlinien zur XML-Formatierung zu einigen, um Vergleichs- und Merge-Operationen zu vereinfachen oder überhaupt erst sinnvoll zu ermöglichen.
Deutlich wird dies durch folgendes Beispiel: Einem Work Item Type (z.B. Product Backlog Item des Scrum Templates) soll ein neues Feld hinzugefügt werden. Dafür sind mindestens zwei Stellen zu bearbeiten. Zunächst muss das neue Feld innerhalb des XML-Tags Fields bekannt gemacht werden. Hier kommt die erste Herausforderung, denn an welcher Stelle innerhalb der genannten XML-Sektion die Felddefinition eingefügt wird, ist aus Sicht des TFS irrelevant. Jedoch ist es für einen Vergleich zweier Dateien unabdingbar, dass man sich auf eine einheitliche Vorgehensweise geeinigt hat. Dies könnte z.B. so aussehen, dass neue Felder stets unten in dem Bereich Fields in alphabetischer Reihenfolge angefügt werden. Eine Alternative ist, die Felddefinitionen so zu sortieren, dass sie mit der Reihenfolge der Elemente an der Oberfläche übereinstimmen.
Die zweite Schwierigkeit in diesem Umfeld ist, dass die XML-Formatierung einheitlich ist. Darunter fallen Punkte wie “Tabulator oder Leerzeichen zum Einrücken” oder die Verwendung von Kommentaren. Auch hier wird die Weiterentwicklung durch eine Vereinheitlichung erleichert.
Wie den vorherigen Erläuterungen zu entnehmen ist, entpuppt sich die nachhaltige Pflege und Weiterentwicklung von Prozess Templates als etwas komplexer als man vielleicht auf den ersten Blick meint. Deshalb ist es umso wichtiger auch die Änderungswünsche der Nutzer kritisch zu hinterfragen und wie in anderen Projekten ein sorgfältiges Requirements Management zu leben. Eine Möglichkeit, die Process Tempaltes stabiler zu halten, ist die Verwendung der Tags, die seit dem Update 2 (TFS 2012.2) zur Verfügung stehen. Damit kann die Anzahl der Änderungen deutlich reduziert werden. Denn alle Anfragen nach weiteren Feldern, um zusätzliche Metainformationen zu speichern, um dann beispielsweise nach weiteren Kriterien auszuwerten, können nun von den Benutzern selbst gelöst werden.
Fazit
Process Template Customization ist sehr ähnlich zu einem Softwareentwicklungsprojekt. Es gilt zunächst, die Anforderungen gründlich zu sondieren. Darüber hinaus müssen gewisse Qualitätskriterien eingehalten werden. Anpassungen des Process Templates müssen auch getestet werden. Schließlich müssen Versionen oder Releases definiert werden, die geordnet veröffentlicht und installiert werden.