Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Barbara Göller

Barbara Göller

Gewusst wie–Tipps und Tricks im Umgang mit den Neuerungen in den Prozess Templates des TFS 2015

Freitag, 09. Oktober 2015

Im ersten Teil dieser kleinen Blogserie wurden die wesentlichen Neuerungen in den Prozess Templates des TFS 2015 beschrieben. Wie Sie mit damit einhergehenden Fallstricken umgehen und was Sie tun müssen um die neuen Elemente in Ihre bereits bestehenden, angepassten Prozess Templates einarbeiten zu können, ist Gegenstand dieses Beitrags.

Grundsätzlich gibt es zwei Ansätze, wie die Vorzüge, welche die Neuerungen in den Process Templates mit sich bringen, für bereits bestehende Templates übertragen werden können. Zum einen können die neuen Elemente in das bestehende Template eingepflegt werden oder aber die Anpassungen des eigenen Templates werden in ein neues nutzerspezifisches TFS Standardtemplate eingearbeitet.

Der erste Ansatz eignet sich vor allem dann, wenn das eigene Template eine Vielzahl an Änderungen enthält und damit einen hohen Anpassungsgrad aufweist. Hinzu kommt, dass in diesem Fall der Configure Features-Wizard nach dem TFS Upgrade verwendet werden kann um das bestehende Template mit den neuen Features auszustatten. Dies setzt jedoch voraus, dass dem eigenen Process Template eines der Standardtemplates zugrunde liegt.

Hingegen eignet sich der zweite Ansatz vor allem für Szenarien, in denen die Anpassungen im Vergleich zum Basistemplate und somit auch der Aufwand der Übertragung sehr gering ist. Dieser Ansatz bringt zudem den Vorteil mit sich, dass man sicher sein kann, alle neuen Features der neuen Templates auch tatsächlich nutzen zu können und nichts übersehen zu haben. In diesem Fall jedoch müssen die Anpassungen manuell in den Quellcode-Dateien des Process Templates vorgenommen werden.

Für diesen Artikel wird für einige der im ersten Teil des Blogs beschriebenen Neuerungen die notwendigen Schritte zur Umsetzung erklärt und zwar mittels des ersten Ansatzes. Dabei wird nicht die Umsetzung mittels des Configure Features-Wizards beschrieben, sondern die notwendigen manuellen Änderungen in den Quellcode-Dateien. Grundsätzlich ist es für beide Vorgehensweisen empfehlenswert ein Tool zum Vergleich der zugrundliegenden XML-Dateien, wie z.B. DiffMerge, zu Rate zu ziehen. Dies hilft vor allem auch dabei, eine Entscheidung im Bezug auf den zu verwendenden Ansatz zu treffen, ob bestehende Änderungen in ein neues Standard Process Template eingepflegt werden sollen oder aber ob umgekehrt die neuen Features in ein bestehendes angepasstes Process Template eingearbeitet werden.

Ein Fallstrick im Zusammenhang mit den Veränderungen der neuen Templates taucht aufgrund der neu eingeführten Unveränderbarkeit der Standard Templates auf, welche über die Guid identifiziert werden. Bisher war es zwar auch Best Practice die Guid sowie den Namen des Templates im Falle von Anpassungen zu verändern, jedoch führte es nicht zu (offensichtlichen) Problemen wenn es mal vergessen wurde. Will man nun also solch ein angepasstes Template in den TFS hochladen, welches aber noch dieselbe Guid wie eines der Standardtemplates besitzt, so erhält man eine Fehlermeldung und kann den Prozess nicht beenden. In diesem Fall muss dem Template in der Datei ProcessTemplate.xml eine neue Guid zugewiesen werden (vgl. Abbildung 1).

image

Abb.1: Fehlermeldung beim Hochladen eines Templates und Ursache im Template

Möchte man die Unterstützung für das Scale Agile Framework (SAFe) in ein bereits bestehendes Template einpflegen so müssen, wie im  ersten Teil beschrieben, zwei Teile implementiert werden. Dies ist zum  einen das Hinzufügen des Work Item Typs Epic und dessen Backlog / Board und zum anderen das Ergänzen des Feldes Value Area für alle Work Iten Typen auf Portfolio-Ebene.

Für die Implementierung des Epic-Work Item Typs sind folgende Schritte auszuführen:

Zunächst muss eine gültige Work Item Definition im Verzeichnis WorkItem Tracking/TypeDefinitions hinzugefügt werden. Hierfür kann die Definition aus einem der drei Standard-Prozess Templates verwendet werden. Dabei sollte die Definition desjenigen Templates gewählt werden, welches dem eigenen Template als Basis zugrunde liegt. Im zweiten Schritt muss dann der Datei WorkItems.xml ein neues Element Workitemtype, welches den Pfad zur Definition spezifiziert, hinzugefügt werden (vgl. Abbildung 2).

SNAGHTML6792639

Abb.2: Categories.xml

Weiterhin muss dann in der Datei Categories.xml eine eigene Kategorie für die Epics definiert werden (vgl. Abbildung 3) , welche schließlich verwendet wird, um das Epic-Portfolio-Backlog  innerhalb der ProcessConfig.xml zu konfigurieren (vgl. Abbildung 4(1)) und den Bezug zum Feature-Portfolio-Backlog zu definieren (vgl. Abbildung 4(2)).

SNAGHTML681d4b2

Abb.3: Categories.xml

SNAGHTML689cbb3

Abb.4: ProcessConfiguration.xml

Zuletzt kann dann dem neuen Work Item Typen Epic in der ProcessConfiguration.xml noch (optional) eine Farbe zugewiesen werden, welche im TFS Web Access benutzt wird um  den Work Item Typen farblich zu markieren (vgl. Abbildung 4(4)).

Hat man diese Schritte durchgeführt und die Änderungen des Prozess Template in einem bestehenden Projekt nachgeladen (durch Benutzung von Witadmin oder aber mit Hilfe des Wizards) bzw. ein neues Projekt damit erzeugt so kann dann im Web Access in den Settings der jeweiligen Teams das Epic-Portfolio-Backlog aktiviert werden (vgl. Abbildung 5).

image

Abb.5: Team Settings – Backlogs

Der zweite Punkt der in den Bereich des SAFe-Support fällt, ist das Hinzufügen des Feldes Value Area für alle Work Iten Typen auf Portfolio-Ebene. Hierbei wird das Feld wie gewohnt zu einem Work Item hinzugefügt (vgl. Abbildung 6).

image

Abb.5: Value Area-Field

Nicht zuletzt noch einige Anmerkungen zu den Neuerungen für den Work Item Typ Bug. Wie bereits im  ersten Teil des Blogs beschrieben sind die Konfigurationsmöglichkeiten für Bugs erheblich gewachsen. Neben dem  im Prozess Template konfiguerbaren Standardverhalten kann ebenso wie das Ein- und Ausschalten von Portfolio-Ebenen die Behandlung von Bugs teamspezifisch in den Team-Einstellungen im TFS Access (Settings) konfiguriert werden (vgl. Abbildung 6).

SNAGHTML6a05857

Abb.6: Team Settings – Bugs

Für das Hinzufügen der dafür benötigten Felder zum Work Item Typ Bug kann die MSDN zur Rate gezogen werden. Alternativ können auch mittels einem XML-Vergleichstool die neu eingeführten Felder herausgefunden werden um dann die Änderungen in das eigene Template zu übernehmen.

Fazit

Abschließend bleibt zu sagen, dass es in den meisten Fällen empfehlenswert ist die Änderungen der neuen Versionen in den eigenen Templates nachzuziehen um auch in Zukunft schnell und einfach Team Projekte mit dem bekannten Template aber mit neuen Features nutzen zu können.  Dies kann zwar einiges an Zeit in Anspruch nehmen, gewusst wie ist das aber kein Hexenwerk.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , ,

Hinterlasse eine Antwort