Ich habe eine TFS-Serverinstallation, bei der im Laufe der Zeit ein Upgrade von TFS 2005 auf TFS 2008 und dann auf TFS 2010 durchgeführt wurde. Während der gesamten Installationsdauer wurden viele Projekte erstellt und verschiedene Projektvorlagen verwendet. MSF Agile 4.0, 4.1, 4.2 und 5.0. und ein paar MSF CMMI.

Ich möchte die Projektvorlage, die für all diese Projekte verwendet wird, "ersetzen", um eine neue zu verwenden: Microsoft Visual Studio Scrum 1.0.

Mir ist bekannt, dass TFS-Projektvorlagen als @ verwendet werde templates zum Erstellen neuer Projekte und kann die tfs-Projektdefinitionen nach dem Erstellen nicht ändern.

Bis jetzt wurden nur die Versionskontrolle und der Build-Server-Teil von TFS verwendet, und es gibt keine vorhandenen Arbeitsaufgabentypen.

Zusätzlich bleiben alle Projekte und Build-Skripte, die von den Quellcode-Pfaden abhängen, gleich.

Wie ich es sehe, habe ich die folgenden Optionen:

Erstellen Sie neue TFS-Projekte mit der richtigen Projektvorlage und verschieben / verzweigen Sie den Quellcode in das neue Projekt.

Aller Code wird in ein temporäres Teamprojekt verschoben.Das alte Projekt wird gelöschtNeues Projekt mit dem ursprünglichen Namen und der korrekten Prozessvorlage wird erstelltCode wird in das neue Teamprojekt verschoben

Temporäres Teamprojekt wird gelöscht

Alle Build-Definitionen müssen neu erstellt werden, was keine Option ist.

Der Quellcode move / branch wird den Versionsverlauf "durcheinander bringen"

Durch die Versionsverwaltung wird der Versionsverlauf durcheinander gebracht. Wenn Sie den Quellcode verschieben, wird er hinter den Kulissen am ursprünglichen Speicherort gelöscht und umbenannt. Der Verlauf befindet sich weiterhin im alten Projekt. Dies erschwert die Suche im Verlauf und wenn ich das alte Projekt tatsächlich lösche, verliere ich den gesamten Verlauf, bevor der Quellcode verschoben wird.

Dies ist wirklich keine Option für mich, da jahrelange Code-Änderungshistorie erforderlich ist, um die verschiedenen Anwendungen zu unterstützen, die erstellt werden.

Verwenden Sie die TFS-Migrationstools, um zu einem anderen TFS-Projekt zu migrieren.

Dies hat die gleichen Nachteile wie die erste Lösung

Arbeitsaufgabentypen ersetzen / importieren, neue Berichte installieren, neue SharePoint-Websites erstellen

Für jedes TFS-Projekt

Bestehende Workitem-Definitionen mit "witadmin deletewitd" löschen

Importieren Sie jede Workitem-Definition aus der neuen Prozessvorlage mit "witadmin importwitd"

Workitem-Kategorien mit "witadmin importcategories" importieren

Alte Berichte im Projektordner auf dem Berichtsserver löschen

Laden Sie die Berichtsdefinitionen aus der neuen Prozessvorlage hoch

Ändern Sie die für die Berichte verwendeten Datenquellen, indem Sie den Berichts-Manager verwenden, um auf die richtigen freigegebenen Datenquellen (TfsReportDS und TfsOlapReportsDS) zu verweisen.

ndern Sie den Standardwert für den Berichtsparameter ExplicitProject auf "" (leere Zeichenfolge) und deaktivieren Sie die Benutzeroption "prompt"

Exportieren Sie die Dokumente auf der alten SharePoint-Website mit stsadm

Löschen Sie die alte SharePoint-Site

Erstellen Sie die Sharepoint-Site mithilfe der TFS2010-Site-Vorlage "Agile Dashboard" neu.

Aktivieren Sie die Site-Funktion "Team Foundation Server Scrum-Dashboard"

In TFS-Projekteinstellungen -> Projektportaleinstellungen: Aktivieren Sie "Teamprojektportal" und stellen Sie sicher, dass die URL korrekt ist. Aktivieren Sie "Berichte und Dashboards beziehen sich auf Daten für dieses Teamprojekt"

Und schlussendlich.

Das Lager bearbeiten

Die Analysedatenbank bearbeiten

Auch wenn dies viele kleine Schritte erfordert, sieht dies ansprechender aus, da diese Option mich nicht zwingt, den Quellcode zu verschieben, und meine vorhandenen Build-Definitionen intakt bleiben.

Meine Frage

Gibt es noch andere Möglichkeiten, um Workitem-Typen zu ersetzen, die ich nicht erwähnt habe?

Und / oder fehlen mir irgendwelche Schritte in der letzten Lösung?