Wie lange haben wir alle darauf gewartet, und nun können wir es endlich: Unsere alten Team-Projekte, die wir aus Unwissenheit schrecklich benannt haben, umbenennen. Wie viele Team Projekte haben Probleme mit der Pfadlänge, weil das Team Projekt alleine schon “myCompany Fabrikam Fiber Version 4 with Updates” heißt? Oder Projekte mit Umlauten im Namen? Ganz zu schweigen von meinem persönlichen Favoriten: dem Rechtschreibfehler.
Nach einer Umbenennung zeigen sich oft einige Fallstricke, die mit einer Checkliste am besten bereits schon vorher abgefangen werden sollten. Ganz nach dem Motto: “Umbenennen, schön und gut, aber ein bisschen komplexer als beim Umbenennen einer Datei wird es wohl doch sein, oder?”
Zunächst einmal ist der Akt des Umbenennens in der Tat simpel: Über die Team Project- oder Collection Web-Oberfläche können wir den Prozess starten.
Der Team Projekt Name steckt in vielen Bereichen des TFS und wird oft referenziert. Damit die Änderung an einer solch zentralen Information keine unangenehmen Nachwirkungen mit sich bringt, sollten wir vorher einige Punkte betrachten.
– TFVC Workspace Mappings
Hierbei unterscheiden wir primär nach Server- und Lokalen Workspaces. Die Server-Workspaces werden zentral verwaltet und das Mapping wird beim ersten Get oder Check In durch ein VS 2010 oder neuer korrigiert. Ähnlich sieht es auch bei Lokalen Workspaces aus. Der Unterschied liegt darin, dass das VS 2010 entfällt. Wie alle älteren Tools unterstützt es nur Server-Workspaces. Hier ist die Empfehlung, die Daten vorher einzuchecken oder zu shelven, und nach dem Umbenennen einen neuen Workspace anzulegen.
Beispielfehlermeldung im Visual Studio 2013 Update 3: Wir müssen zuerst das VS 2013 Update 5 installieren.
– Was passiert mit den Links auf den WebAccess oder Work Items?
Gute Nachricht: Sofern der alte Name eines Team Projektes nicht erneut verwendet wird, existiert eine automatische Umleitung.
Und das gleiche Verhalten bei Work Items:
Sowohl die Basis des Area-Path als auch des Iteration-Path wurden geändert.
– Reporting
Das in der On-Premise Version des TFS angebundene SQL Server Reporting Services System (SSRS) wird durch den Prozess des Umbenennens ebenfalls beeinflusst. Leider aber ohne eine Weiterleitung vom alten Projekt.
Error: “FabrikamFiber cannot be found”
– Was sollten die Anwender machen?
Da die meisten Team Foundation Version Control Anwender ihre Maschinen täglich neu starten, sollte kaum ein Problem auftreten. Falls doch: Alle mit dem umbenannten System Arbeitenden sollten einmal durchstarten.
– Was muss bei git gemacht werden?
Die Repository URL beinhaltet neben dem Repo-Namen auch den Team Projekt Namen. Git-Benutzer tragen unter “Settings” im Team Explorer die neue URL ein. Puristen, die über die Kommandozeile agieren, verwenden den Befehl:
“git set-url remote origin [remote-repo-url]”
– Und was ist mit Excel, Project (client) und Storyboarding (Power Point)?
Diese Tools kommen mit dem Umbenennen sehr gut zurecht. Ein einfacher Neustart der Applikation reicht aus, um die Aktualisierung durchzuführen. Andernfalls erscheint folgende Fehlermeldung:
TF80083: Team Foundation could not retrieve the work item from the database.
– Unterstützt WordToTFS diese Funktion?
Die Antwort ist ja und nein. Da wir noch keine dedizierte Version für den TFS 2015 veröffentlicht haben, können wir derzeit nur die Version “WordToTFS 4.5” für den TFS 2013 verwenden. Um nach einer Umbenennung weiter arbeiten zu können, müssen wir manuell das Dokument mit “Disconnect” vom Projekt lösen und neu verbinden.
– Und was passiert wenn wir die Project Server Integration verwenden?
Rufen Sie uns am besten vor dem Umbenennen an.
– Funktionieren die Work Item Queries anschließend noch?
Klingt logisch: Alle Work Item Queries die mit dem Parameter “@Project” ausgeführt werden, funktionieren weiterhin. Aber noch besser: Auch wenn der Team Projekt-Name explizit gesetzt wird, wird er automatisch aktualisiert.
Fazit
Wir sehen, es wird nahezu alles umbenannt, was im Kontext des Projektes als Objekt existiert: Report Ordner, Source Control, Work Items… Die einfachste Lösung, um Probleme zu verhindern, ist also, dass wir bereits im Vorfeld alle Arbeiten im Projekt speichern bzw. einchecken und schließen. Denn eines ist sicher: Es wird definitiv für die Team-Mitglieder eine (kurze) Arbeitsunterbrechung geben.