Planung

Die spontane Antwort auf die Frage „Was soll migriert werden“ wird üblicherweise mit „Alles“ beantwortet. Das ist aber gar nicht so einfach und auch nicht unbedingt sinnvoll.

In der Regel existiert bereits eine Source Code Verwaltung auf Basis Visual Source Safe (VSS), Subversion, Clear Case o.a. Diese beinhalten nicht nur den Source Code, sondern auch wichtige Meta-Information wie:

• Branches
• Labels
• Kommentare
• Verknüpfungen
• Berechtigungen
• Dateiversionen und deren Delta-Informationen (Unterschiede zwischen zwei Versionen)

Diese Informationen lassen sich gar nicht – oder nur mit enormen Aufwand – verlustfrei zwischen den verschiedenen Herstellern migrieren. Zu unterschiedlich sind die internen Mechanismen der Systeme.

Wer führt die Migration durch?

Falls es nicht zufällig eine spezielle Task Force (d.h. eine eigenes Projektteam) für die Migration gibt, bleiben die Arbeiten der Migration am Softwareentwicklerteam hängen. Die Arbeiten hierzu müssen im Rahmen der üblichen Featureplanung zusätzlich untergebracht werden. In der Konsequenz bedeutet dies, dass die Migration nicht viel Zeit kosten darf.

Muss alles migriert werden?

Es hilft sich klar zu machen, dass eine Versionsverwaltung üblicherweise zwei Zwecken dient.

Zweck 1 hilft dem Team die aktuelle Tagesarbeit zu bewältigen. Es ermöglicht zeitgleich mit unterschiedlichen Branches und Versionen auf einem gemeinsamen Source-Stand zu arbeiten. Die verschiedenen Stände können kombiniert oder auch zurückgerollt werden.

Das Entwicklerteam benötigt nach einer TFS Migration für seine Tagesarbeit die aktuellen Branches und Versionen. Im Extremfall beschränkt sich das auf den aktuellen Main-Branch.

Zweck 2 besteht aus einer Revisionspflicht. Damit werden Nachweise geführt, wann welche Änderungen durchgeführt wurden. Für eine Revisionspflicht reicht es in der Regel ausschließlich die ausgelieferten Versionsstände zu betrachten. Die vielen kleinen Zwischenstände der Tagesarbeiten spielen nach Jahren keine Rolle mehr. Der Nachweis muss zudem nicht notwendigerweise im aktuellen Source System geführt werden. Hierzu gibt es durchaus Alternativen:

· Wichtige Label-Stände werden in Archive gezogen

· Check-In Kommentare werden pro Datei in PDF Reports ausgelagert

· Finale Stände von Branches werden in Archive gezogen

Wenn es die Lizenzgestaltung erlaubt, kann die alte Source Verwaltung auch im Read-Only Modus weiter betrieben werden, so dass das System für Revisionszwecke weiterhin zur Verfügung steht.

Wenn es mehr sein soll

Sollen viele Softwareprojekte umgestellt werden oder möglichst viele Metainformationen zu Branches, Labels, Check-Ins, Berechtigungen etc. aus dem Altsystem übernommen werden, wird Unterstützung durch Spezialisten nötig. Es empfiehlt sich hier dringend eine spezielle „Migration Task Force“ einzurichten. Diese hat dann die Aufgabe Tools für den automatisierten Übergang zu evaluieren und die Entwicklerprojekte in der Umstellung zu unterstützen und zu beraten.

Für die Umstellung von ClearCase gibt es ein umfangreiches White Paper [ClearCaseTfs], das Vorgehen und Toolunterstützung detailliert beschreibt.

Fazit und Vorschau auf Teil 2

In der Regel reicht es, die aktuellen Developer-Branches und Produktions-Branches zu migrieren. Für Revisionszwecke können alternative Archivierungsmethoden genutzt werden. Die Minimierung des Migrationsumfanges kommt dem Software-Entwicklerteam sehr entgegen, da sie in der Regel nicht viel Zeit bekommen eine TFS Migration durchzuführen.

Im zweiten Teil werde ich anhand dreier unterschiedlicher Beispiele aufzeigen, wie der zeitliche Ablauf einer Source-Migration für Branches vorgenommen werden kann.

Links

[MS_ALM] Application Lifecycle Management
http://www.microsoft.com/visualstudio/en-us/strategies/alm

[ClearCaseTfs] Migration ClearCase to Team Foundation Server
http://download.microsoft.com/download/9/2/3/923D72FB-0076-49B6-96C4-AAC1C255A60E/WhitePaper_Migration_ClearCase_to_TFS_V1.0.pdf