Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Thomas Rümmler
Thomas Rümmler arbeitet als Managing Consultant und Projektleiter bei AIT und ist von Microsoft als Most Valuable Professional (MVP) für Visual Studio & Development Technologies ausgezeichnet worden. Sein Arbeitsschwerpunkt liegt auf Application Lifecycle Management und DevOps. Thomas hilft Unternehmen ihren Entwicklungsprozess ganzheitlich zu verbessern. Seine Erfahrung gibt er als Autor des TFS-Blogs und Sprecher im Microsoft DevOps Umfeld weiter.

Thomas Rümmler

Umzug mit Tücken – Migration eines Teamprojekts innerhalb einer Collection

Freitag, 15. April 2011

Viele Unternehmen starten mit dem TFS in ein oder mehrere Pilotphasen. Häufig gibt es am Anfang eine isolierte Umgebung, liebevoll Sandbox oder Spielwiese getauft, mit der die Teammitglieder an das Machwerk TFS herangeführt werden.

Da der TFS bekanntlich sehr schnell begeistern kann, hat man manchmal schon in solchen Testumgebungen Source Code  und andere Artefakte, die plötzlich doch nicht mehr nur Pilotcharakter haben und man diese beim Sprung in die Produktivumgebung im Tandem mitnehmen muss.

Wer schon einmal eine Migration von Daten im TFS durchgeführt hat, weiß, dass man dafür eine ganze Menge Aufwand spendieren kann. Hier bewährt sich wieder der gute alte Pareto (vgl. http://de.wikipedia.org/wiki/Paretoprinzip). Wenn man sich also von ein paar Dingen verabschiedet, kann solch ein Wechsel ganz unproblematisch ablaufen.

Was geht und was geht nicht?

Dabei kann man sich an folgendem Ablauf orientieren:

· Anlegen eines neuen Team Projects unter Verwendung des gewünschten Process Templates

· Übernahme von Source Code

· Übernahme von Area und Iteration Pfaden

· Übernahme von Work Items (außer Test Cases)

· Übernahme von Test Cases

Den Absprung überleben nicht:

· Verlinkungen zwischen den Work Items (außer Parent-Child-Beziehungen)

· Attachments

· Work Item Historie

· Systemfeldwerte, z.B. CreatedBy, StateChangeDate und CreatedDate

· Testpläne

· Testergebnisse

· Formatierung in HTML-Feldern

Drum prüfe…

Um vor der Übernahme zu prüfen, wie viele Work Items es mit bzw. ohne Attachments gibt, kann man sich eine Work Item Query erstellen und auf das Feld Attached Field Count abfragen (vgl. Abbildung 1).

clip_image002

Abbildung 1: Work Item Query Definition

Team Project anlegen

Zu Beginn brauchen wir natürlich ein neues Team Project. Aufgrund der später verwendeten Werkzeuge ist es hilfreich, wenn dieses Team Project in der gleichen Project Collection angelegt wird, wie das Ursprungssystem, welches im weiteren Verlauf die Datenquelle für Source Code & Co. repräsentiert.

Source Code umziehen

Nachdem das Team Project angelegt ist, kann man auch schon mit dem Umzug des Source Codes beginnen. Dazu legt man sich ein lokales Mapping über den Source Control Explorer in Visual Studio an. Anschließend zieht man die Source Ordner auf Root-Ebene im Team Project mittels des Befehls "Move", z.B. aus dem Kontextmenü, um (vgl. Abbildung 2).

clip_image004

Abbildung 2: Source Struktur nach dem Move aber vor dem Einchecken

Nach einem abschließenden Kontrollblick, kann man die Move-Aktion über den Pending-Changes-Dialog einchecken. Damit hat man bereits den ersten Schritt geschafft. Source Code ist sicher gelandet!

Beachten sollte man noch, dass nach Abschluss der Migration das Quell-Team-Project nicht gelöscht wird. In dem Falle würde die gesamte Historie der Dateien verloren gehen. Um das alte Team Project am Ende vor den Benutzern zu verstecken, entzieht man einfach allen Gruppen jegliche Berechtigung auf das Team Project.

Übernahme von Area und Iteration Pfaden

Auf geht’s zur zweiten Runde. Mit der Übernahme der Werte für Area und Iteration legt man einen Grundstein für die erfolgreiche Migration der Work Items inkl. dieser Eigenschaften. Wer bei der Gelegenheit Area und Iteration ausmustern oder runderneuern möchte, kann diesen Punkt überspringen, muss jedoch später bei der Work Item Migration explizit auf diese Werte verzichten.

Für die Übernahme eignet sich das Werkzeug Area Import/Export Tool (siehe http://msmvps.com/blogs/vstsblog/archive/2007/07/07/copy-area-and-interation-structure-using-the-area-import-export-tool.aspx)

Zuerst verbindet man sich mit dem Tool auf das Quell-Team-Project und führt einen Export aus (vgl. Abbildung 3).

clip_image006

Abbildung 3: Export mit dem Area Import/Export Tool

Auf die gleiche Art werden die Strukturen, die mittlerweile als Datei vorliegen, in das Ziel-Team-Project importiert.

Übernahme von Work Items (außer Test Cases)

Bei den Work Items geht man am besten die verschiedenen Work Item Typen nacheinander durch. Empfehlenswert ist es, mit einem Work Item Typ zu beginnen, von dem es die geringste Menge an erzeugten Work Items gibt – als kleine Eingewöhnungsphase.

Hierfür erstellt man sich über den Team Explorer in Visual Studio eine Work Item Query im Quell-Team-Project und eine im Ziel-Team-Project. Beide Abfrageergebnisse öffnet man dann in Microsoft Excel (vgl. Abbildung 4).

clip_image008

Abbildung 4: Work Item Query in Microsoft Excel öffnen

Dabei lässt man sich in beiden Excel-Sheets zu Beginn alle Spalten anzeigen.

Als nächstes muss man, falls sich die Work Item Definitionen unterschieden, z.B. Attribute unterschiedlich benannt, entfernt oder hinzugekommen sind, die Spalten-Strukturen angleichen. Dank großer Auflösung, kann man die zwei Excel-Sheets bequem übereinander anordnen und Spalte für Spalte durchgehen (vgl. Abbildung 5).

clip_image010

Abbildung 5: Matching der Work Item Attribute mittels Microsoft Excel

Im Beispiel in Abbildung 5 wird eine Work Item Query vom List type Flat verwendet. Dabei gehen jegliche Abhängigkeiten verloren. Wenn es bei den Work Items bestehende Parent-Child-Beziehungen gibt, die mit migriert werden sollen, dann verwendet man hier den List type Tree of Work Items.

Um bei diesem Schritt für etwas mehr Übersichtlichkeit zu sorgen, sollte man nicht verwendete Spalten beim Überprüfen in beiden Excel Sheets ausblenden. Falls es in der Zielumgebung neue Pflichtfelder gibt, die keinen Standardwert haben, so blendet man diese am besten ganz rechts im Excel-Sheet des Ziel-Team-Projects ein. Dadurch kann man die Zeilen aus dem Quell-Excel-Sheet komplett kopieren und danach im Ziel-Excel-Sheet die letzten Spalten durch passende Werte vorbelegen.

Außerdem ist es hilfreich, sich die Spalten State und Reason noch einmal rechts außerhalb der Query-Ergebnisse einzufügen. Beim Import der Work Items in das neue Team Project erhalten sie in ihrem Lebenszyklus alle den Initialzustand. Um die Work Items später wieder in einen dem urspränglichen Zustand entsprechen Status zu versetzen, ist es nützlich, wenn man diese Information zu jedem Work Item noch zur Verfügung hat.

Nachdem die Spalten richtig konfiguriert und die Zeilen kopiert sind, führt ein beherzter Klick auf den Publish-Button im Team-Ribbon in Excel zum zweiten Absprung.

Diese Schritte müssen nun noch für alle anderen Work Item Typen durchgeführt werden, von denen es instanzierte Work Items gibt. Ausnahme: Test Cases.

Übernahme von Test Cases

Da man Test Cases nicht mit Microsoft Excel ex- und importieren kann, greifen wir zu einem weiteren Werkzeug in unserem Rucksack. Wir bedienen uns des Test Case Migrators (vgl.

http://blogs.microsoft.co.il/blogs/shair/archive/2011/03/20/test-case-migrator-between-projects-wpf-metro.aspx).

Für den Einsatz dieses Werkzeuges ist es erforderlich, dass Quelle und Ziel jeweils Team Projects in der gleich Project Collection sind.

Zunächste wird die Verbindung zum TFS konfiguriert (vgl. Abbildung 6).

clip_image012

Abbildung 6: Test Case Migrator – Connection

Als nächstes überprüft das Programm, ob die Test Cases im Quell- und Ziel-Team-Project die gleiche Struktur haben. Ist dies nicht der Fall, kann man die Migration nicht fortsetzen (vgl. Abbildung 7).

clip_image014

Abbildung 7: Test Case Migrator – Mapping Check fehlgeschlagen

Im Falle von nicht übereinstimmenden Strukturen, muss man die Work Item Definitionen im Quell- und Zielsystem für die Testcases sowie die dazugehörigen Shared Steps zumindest vorübergehend angleichen. Im Beispiel hier bedeutet dies, dass man im Zielsystem das Feld "Priority" hinzufügt sowie den Zustandsautomaten (Bezeichnungen für State und Reason) anpasst. Nach erfolgreichem Portieren, kann man diese Änderungen wieder rückgängig machen, also eingefügte Felder wieder entfernen und die Zustände wieder umbenennen.

Nachdem die Strukturen vereinheitlicht wurden, kann man über eine geeignete Work Item Query, die man sich vorher im Team Explorer angelegt hat, die zu überführenden Test Cases auswählen (vgl. Abbildung 8).

clip_image015

Abbildung 8: Test Case Migrator – Auswahl der zu migrierenden Work Items

Mittels Start kann es also auf gehen, in den letzten Sprung des Tages.

Sind wie im vorher gezeigten Beispiel die Bezeichner für State und Reason verändert worden, so muss dies noch abschließend gerade gezogen werden. Man tauscht hierzu die für die Migration modifizierte Work Item Type Definition durch die korrekte Definition des Zielsystems aus. Anschließend öffnet man über eine Work Item Query alle Test Cases in Microsoft Excel. Hier können State und Reason ganz bequem verändert werden, damit sie der definition des neuen Process Templates entsprechen.

Fazit

Wenn man bereit ist, nicht jede Information mit ins neue Team Project zu übernehmen, dann kann die Migration mit vertretbarem Aufwand durchgeführt werden. Dabei ist die Übernahme von Artefakten aus einem bereits bestehenden Team Project in ein neues sogar bei massiven Abweichungen im Process Template relativ einfach möglich.

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