Durchführung – Nur Main-Branch

Die einfachste Möglichkeit eine Migration durchzuführen besteht im Übertrag der Sourcen des Main-Branches in den TFS Source Control. Am Tag der Migration wird die alte Source Code Verwaltung (in der Grafik mit SVN dargestellt) gesperrt und alle Sourcen in den TFS kopiert.

Nach Fertigstellung kann das Entwicklerteam in der neuen Umgebung weiterarbeiten. Zusätzlich müssen alle Systeme, die die Versionsverwaltung als Datenquelle benutzen, umgestellt werden. Primär spielt hier ein Nightly Build eine Rolle, der seine Sourcen ab sofort aus dem TFS ziehen muss. Des Weiteren können aber auch Excel, Text oder andere Datenquellen eingecheckt sein, die von Fachabteilungen oder Fremdsystemen genutzt werden. Am Tag der Umstellung müssen diese alle auf die neue Quelle zugreifen.

Durchführung – Migration von Branches

Verlässt man die Stufe ganz einfacher Softwareentwicklungsprojekte, so existieren einer oder mehrere Branches. Um den initialen Aufwand niedrig zu halten kann es sinnvoll sein, zeitlich entkoppelt einen Branch nach dem Anderen auf den TFS umzuziehen. Somit ergibt sich eine Übergangsphase in der beide Versionierungssystem aktive Branches beinhalten.

Hierdurch bekommt man die zusätzlich die Sicherheit, dass man den gerade aktuellen Produktions-Branch unangetastet lassen kann.

Für das nachfolgende Beispiel nutze ich die beliebte – da überschaubare – Strategie „Branch on Deployment“ (siehe [BranchPrimer]). Dabei wird für jedes Auslieferungs-Release ein eigener Branch erstellt. Bugfixes werden auf dem Release-Branch durchgeführt und nach Main gemerged.

Im ersten Schritt empfiehlt es sich, den Main-Branch nach TFS zu übertragen. Er bildet die Basis für zukünftige Releases. Der beste Zeitpunkt hierfür ist kurz nach einem durchgeführten Release. Im nachfolgenden Beispiel wurde für die Version 3.0 ein produktiver Branch erstellt. Kurz danach kann die Migration des Main-Branches (=> „Main Migration“) erfolgen.

Interessant wird der Zeitpunkt, an dem Fehlerbehebungen auf dem Produktions-Branch (hier auf SVN) durchgeführt werden. Spätestens am Tag des Deployment (=> „Prod Patch“) sollten diese auf den Main-Branch zurück geführt werden. Das ist aber gar nicht so leicht, da der Main-Branch in der Zwischenzeit auf dem TFS liegt und selber verändert worden sein kann. Ein automatisierter Merge ist somit nicht mehr möglich, da die Basisinformation für einen 3-Wege-Merge [3WayMerge] über die Toolgrenze nicht funktioniert.

Über einen Zwischenschritt kann man sich die Arbeit erleichtern. Zuerst wird ein automatisierter Merge (kleiner blauer Pfeil) auf den – eigentlich stillgelegten – SVN-Main-Branch durchgeführt. Das hierzu erstellte Änderungsprokoll nutzt man zur Qualitätssicherung des manuellen Merges (kleiner orangener Pfeil) in den TFS.

Ein nachfolgendes Release 4.0 mit eigenem Branch stellt dann kein Problem mehr dar (=> „Neuer Prod Branch“). Der „alte“ SVN Produktions-Branch wird beendet und ein neuer TFS Produktions-Branch eröffnet.

Welcher Leser hat’s gemerkt? Der angekündigte „niedrige initiale Aufwand“ ergibt sich daraus, dass faktisch nur der Main-Branch in das neue System überführt wird. Der Produktions-Branch verbleibt im alten System. Somit bietet sich diese Verfahren an, wenn nur wenige Produktions-Patches zu erwarten sind. Zudem muss man die Möglichkeit haben das alte und neue System über einen gewissen Zeitraum parallel zu betreiben.

Durchführung – Parallele Migration von Branches

Wird das alte Source Control System stillgelegt, so müssen alle relevanten Branches fast zeitgleich auf den TFS übertragen werden. Im Prinzip ist das eine recht einfach Aufgabe. Am Tag der Migration wird der Main-Branch erzeugt und alle bisherigen Main-Sourcen aus dem Altsystem kopiert und eingecheckt.

Als nächsten Schritt erzeugt man den TFS-Prod-Branch als Kind des Main-Branches. Wichtig ist dabei, dass alle Dateien im Basis-Branch vorhanden sind d.h. der Prod Branch darf erst dann erzeugt werden wenn alle Dateien von Main migriert und eingecheckt sind. Der Zeitpunkt der Branch-Erstellung definiert den Ausgangspunkt für spätere Merge-Operationen. Wird auf Basis eines leeren Main-Branch ein Prod-Branch erstellt, so werden alle kopierten Dateien als „Neu“ angesehen und es kommt später zu einer immensen Anzahl an Merge-Konflikten.

In der Konsequenz muss die Reihenfolge der Branch-Struktur des alten Source Control Systems eingehalten werden und Stück für Stück nachgezogen werden.

Fazit

Die Migration von Sourcen und Branches in den TFS will technisch und zeitlich gut geplant sein. Wenn es möglich ist, sollten nur die Informationen des alten Systems übernommen werden, die für die Weiterentwicklung unbedingt notwendig sind. Im günstigsten Falle werden allein die Sourcen von aktiven Branches benötigt.

Links

[BranchPrimer] Branching and Merging Primer
http://msdn.microsoft.com/en-us/library/aa730834%28VS.80%29.aspx

[3WayMerge] Three-Way Merge
http://en.wikipedia.org/wiki/Merge_%28revision_control%29#Three-way_merge