Team Foundation Server

Anleitung zu Visual Studio  Team Project und Collection

Willy-Peter Schaub und Mike Schimmel

Im MSDN Magazine-Artikel, “Anleitung zu Branching und Merging in Visual Studio” (msdn.microsoft.com/magazine/gg598921) stellten die Visual Studio ALM Ranger einige neue Branching-Szenarien, um Sie bei realen Branching- und Merging-Umgebungen zu unterstützen, damit Sie die Konsistenz und die Qualität von Lösungen und den allgemeinen ALM- (Application Lifecycle Management) Prozess verbessern können.

Die Ranger sind eine Gruppe von Experten, die sich für die Zusammenarbeit zwischen Visual Studio-Produktgruppen, Microsoft Services und der MVP- (Microsoft Most Valuable Professional) Community einsetzen, indem sie fehlende Funktionen ansprechen und Hindernisse für die Annahme der Technologie beseitigen.

In diesem Artikel bieten die Rangers eine Anleitung für die Organisation und die Bereitstellung von Team Foundation Server (TFS) Team Projects und Team Project Collections.

Nach dem Lesen dieses Artikels sollten Sie folgende Bereiche besser verstehen:

• Team Project Collections und ihre Vorteile
• Überlegungen zur Auswahl mehrerer Team Projects zur Kombination in einer einzigen Team Projects Collection, oder dazu, sie in einzelnen Team Project Collections separat zu halten
• Überlegungen zur Organisation von Team Projects und Team Project Collections zur Steigerung der Isolation oder zur Verbesserung der Skalierbarkeit
• Archivierung eines oder mehrerer inaktiver Team Projects

Dieser Artikel hilft Ihnen dabei zu verstehen, wie die Organisation von Team Project und Team Project Collection von folgenden Bereichen beeinflusst wird:

• Sicherheit und Bereitstellung für TFS, Team Project Collections und Team Projects
• Auswahl einer Prozessvorlage
• Anpassungen von Prozessvorlagen, einschließlich angepasste Workflows, Anpassungen von Arbeitsaufgabentypen, angepassten Berichten, Anfragen und angepasster Prozessanleitung
• Teamorganisation
• Team Project-Organisation, einschließlich Bereiche und Iterationen
• Projektmanagementüberlegungen, einschließlich Projektmeilensteine und Zeitpläne

Planung

Die Visual Studio TFS-Planung beginnt normalerweise mit der empfohlenen Infrastruktur und der Strukturierung der Team Projects und der Team Project Collections, um ein effektives und skalierbares ALM-System für alle Beteiligten sicherzustellen.

Die Visual Studio 2010 Quick Reference Guidance (vs2010quickref.codeplex.com) und Visual Studio 2010 und TFS 2010 Virtual Machine (VM) Factory (rangersvsvmfactory.codeplex.com) Rangers-Guidanceprojekte bieten Konzepte, Anleitungen und Kurzreferenzposter zur Unterstützung der Kapazitätsplanung und zur Hilfe bei der Beantwortung der Frage, ob die Infrastruktur physisch, virtuell oder beides sein soll.

Obwohl Sie typischerweise eine Team Project Collection vor einem Team Project in einer TFS 2010-Umgebung planen und definieren, behandeln wir zuerst das Team Project.

Visual Studio Team Projects

In TFS 2005 und TFS 2008 konnte ein einzelner TFS-Server ein oder mehrere Team Projects hosten. Jedes Team Project ist eigentlich ein Container von Artefakten, darunter Sourcecode (organisiert in Ordnern, verzweigten Ordnern und Verzweigungen) und eine oder mehrere Visual Studio-Lösungen, Team Build-Konfigurationsdateien, Team Load Test Agents, ein optionales SharePoint -Repository mit den relevanten Dokumenten für das Projekt und Sicherheitsbereitstellungen, mit deren Hilfe das Team im Rahmen einer Prozessvorlage eine Reihe von Aufgaben durchführt. Das Team Project sollte nicht mit einem Visual Studio .NET-Projekt verwechselt werden, das alle Build- und Konfigurationseinstellungen enthält, die für die Generierung eines Microsoft .NET Framework Assemblys erforderlich sind, oder mit einer Visual Studio .NET-Lösung, die ein oder mehrere Visual Studio .NET-Projekte enthält und Projektabhängigkeiten, Buildprozess und Reihenfolge definiert, oder mit einer Projektinitiative, einer geplanten Initiative für den Aufbau eines Projekts aus einer Reihe von Anforderungen.

Weitere Informationen zum Erstellen und Verwalten von Team Projects finden Sie auf der MSDN-Bibliotheksseite “Erstellen und Verwalten von Team Projects” (bit.ly/eCP0yX).

Sehen wir uns einige Überlegungen zur Organisation von Project Initiatives in Team Projects an. Team Projects enthalten oft die größte Arbeitseinheit, die zur Entwicklung eines einzelnen Produkts oder einer Produktserie gehört. Beispielsweise sind bei Microsoft Visual Studio und Office zwei Produktserien, die jeweils zu einem eigenen Team Project gehören (vgl. Abb. 1), da die Entwicklung dieser beiden Produktserien vollständig unterschiedlichen Zeitvorgaben mit verschiedenen Meilensteinen und Freigabezeitplänen folgt.

Abbildung 1 Visual Studio- und Office- Team Projects

Es ist wichtig, Überlegungen zur Bereitstellung und zur Sicherheitsisolation anzustellen. Einer der zeitraubendsten Aspekte bei der Erstellung eines neuen Team Projects ist der Aufwand für die Bereitstellung eines Projekts zur Verwendung durch ein oder mehrere Teams, hauptsächlich durch die Definition der Sicherheitsanwender, Gruppen und Berechtigungen, die den Zugriff auf ein Team Project und seine Artefakte steuern. Dieser Bereitstellungsaufwand muss gegen die Vorteile der korrekten Definition der Sicherheit auf der richtigen Granularitätsebene abgewogen werden, damit die Mitglieder des Teams tun können, was sie tun müssen. Gleichzeitig schützt eine korrekte Sicherheitsbereitstellung ein Team Project und seine Ressourcen vor unbeabsichtigten oder beabsichtigten Schäden durch Personen, die bestimmte Aufgaben nicht ausführen sollten.

Für Produktserien mit unterschiedlichen Meilensteinen und Freigabezeitplänen, wie etwa Visual Studio und Office, ist es sinnvoll, jede Produktserie aus Sicherheitsisolationsgründen in einem separaten Team Project zu organisieren. Die Entwicklungsteams der verschiedenen Produktserien sind wahrscheinlich vollständig voneinander getrennt und benötigen wahrscheinlich keine Beitrags- oder Buil-Berechtigungen für beide Teamumgebungen.

Für Projektinitiativen mit unterschiedlichen Methodologien – etwa, wenn ein Team das Microsoft Solutions Framework (MSF) für Agile Software Development Version 5.0 und das andere das MSF für CMMI Process Improvement Version 5.0 Process Template auswählt - sind separate Team projects erforderlich, da ein bestimmtes Team Project nur eine einzige Prozessvorlage hat.

Für Projektinitiativen, bei denen eindeutige Definitionen für Bereiche und Iterationen erforderlich sind, empfehlen wir separate Team Projects, da ein bestimmtes Team Project die einzelne Bereichs- und Iterationshierarchie definiert. Als Alternative kann ein einzelnes Team Project Bereiche verwenden, um mehrere Feature-teams zu organisieren (vgl. Abbildung 2), die die gleichen Iterationen gemeinsam haben (vgl. Abb. 3). Vgl. auch “Projekt v. Projekten mit Team Foundation Server 2010”, von Martin Hinshelwood unter bit.ly/hSnHGw für ein Szenario mit Bereichen anstelle mehrerer kleiner Team Projects.

Abbildung 2 Team Project mit Bereichen zur Organisation separater Feature-Teams

Abb. 3 Team Project mit mehreren Feature-Teams, die die gleiche Iterationshierarchie nutzen

Version Control Check-out-Einstellungen (wie etwa exklusiver Check-out, Check-in-Richtlinien und Check-in-Hinweise) werden für ein Team Project definiert, und diese Einstellungen werden nicht über Team Project-Grenzen hinaus gemeinsam genutzt. Wenn separate Projektinitiativen unterschiedliche Quellcodeverwaltungseinstellungen erfordern, müssen sie separaten Team Projects zugeordnet werden.

Zur Anpassung von Prozessvorlagen gehören angepasste Work Flows, Arbeitselementtypen (WITs), Berichte und Abfragen. Sie können die für die Erstellung neuer Teamprojects verwendete Prozessvorlage anpassen, oder die bestimmte Prozessvorlage, die ein Team Project verwenden, wobei letzteres nicht für mehrere Team Projects gemeinsam ist.

Die gemeinsame Nutzung von Team Project-Artefakten wird normalerweise durch die Verzweigung von einem Team Project zu einem anderen erreicht. In unserem vorherigen Artikel haben wir verschiedene Konzepte für die gemeinsame Nutzung gemeinsamen Codes besprochen, wobei es meistens um Verzweigungen ging.

Wie Sie sehen, gibt es eine Reihe von Überlegungen bei der Entscheidung, ob separate Projekte oder Projektinitiativen in einem Team Project angesiedelt werden sollen oder ob sie besser separaten Team Projects zugewiesen werden. Sie sollten diese Überlegungen verstehen und Team Project-Entscheidungen fällen, die am besten zu Ihrer Organisation passen.

Visual Studio Team Project Collections

Obwohl Team Projects einigermaßen voneinander unabhängig sind, gestalteten sich einige Verwaltungsaufgaben in TFS 2005 und TFS 2008, wie etwa die Konsolidierung mehrerer TFS-Server in einen einzigen Server, ziemlich schwierig. Darüber hinaus konnten separate Geschäftseinheiten innerhalb einer Organisation nur dann organisatorische Isolation erreichen, wenn zwei oder mehr TFS-Server implementiert wurden, was die Kosten der Infrastruktur und die Wartung erhöhte und allgemein zu mehr Komplexität führte

Visual Studio 2010 führte dann Team Project Collections ein. Jeder TFS-Server kann eine oder mehrere Team Project Collections haben. Jede Team Project Collection wiederum enthält ein oder mehrere Team Projects. Eine Project Collection ist die grundlegende Wiederherstellungseinheit für TFS. Im Hinblick auf Sicherung und Wiederherstellung ähnelt eine team Project Collection einer SharePoint Site Collection.

Das Visual Studio 2010 Quick Reference Guidance-Projekt(vs2010quickref.codeplex.com) bietet ein Schnellreferenzposter, das Ihnen bei der Planung des neuen Team Project Collection-Features sowie von Team Projects hilft. Team Project Collections ermöglichen eine skalierbare Bereitstellung für TFS-Server. Eine Team Project Collection in TFS 2010 ist das grobe Äquivalent eines TFS-Server in TFS 2005 oder TFS 2008. Weitere Informationen zur Erstellung und Verwaltung von Team Project Collections finden Sie unter msdn.microsoft.com\library\dd236915.

Überlegungen zur Isolation von Team Projects in separate Team Project Collections betreffen Skalierbarkeit, Sicherung, Wiederherstellung, Sicherheitsisolierung und Weitergabe von Informationen zwischen Team Projects.

Die Skalierbarkeit von TFS-Servern wird durch die Möglichkeit unterstützt, einen Lastenausgleich zwischen Team Project Collections über physische SQL Server und SQL Serverinstanzen hinweg durchzuführen, wobei eine Skalierbarkeits- und Lastenausgleichsinfrastruktur genutzt wird, wie sie typisch für Datenbankumgebungen ist. Wenn Sie die Möglichkeit zum Lastenausgleich über SQL-Server hinweg haben, können Sie von der Aufteilung von Team Projects auf mehrere Team Project Collections profitieren.

Wie bereits erwähnt, ist die grundlegende Wiederherstellungseinheit in TFS die Team Project Collection. Team Projects können nicht einzeln gesichert oder wiederhergestellt werden. Wenn Sie granulare Sicherung und Wiederherstellung benötigen (etwa, wenn Sie nicht mehr als ein einzelnes Team Project wiederherstellen möchten), kann es nützlich sein, Team Projects für Sicherungs- und Wiederherstellungsprozesse in separate Team Project Collections zu isolieren.

Die Sicherheitsbereitstellung für Team Project Collections, wenn korrekt und mit der ausreichenden Kontrolle und Granularität durchgeführt, kann sehr zeitraubend sein. Wenn Sie neue Team Project Collections hinzufügen, müssen Sie an den anfänglichen und fortdauernden Aufwand für die Bereitstellung dieser Sammlungen denken. Wenn die Projektteams der auf einem TFS-Server verwalteten Team Projects unterschiedliche Sicherheitsanforderungen haben, kann es nützlich sein, für Sicherheitszwecke Team Projects in separaten Team Project Collections zu isolieren.

Wenn dies jedoch nicht erforderlich ist, kann es für Ihre Organisation nützlich sein, ihre Team Projects in der selben Team Project Collection zu haben (vgl. Abb. 4).

Abb. 4 Weitergabe- und Isolationsgrenzen von Team Project Collections

Während die gemeinsame Nutzung von Artefakten (wie etwa Sourcecodedateien) zwischen Team Projects in derselben Team Project Collection stattfinden kann, ist dies über Sammlungsgrenzen hinweg nicht möglich (vgl. Abb. 4). Wenn zwei Team Projects Artefakte gemeinsam nutzen müssen, müssen sich diese in der selben Team Project Collection befinden.

Das Thema der Verwendung von Team Project Collections für die gemeinsame Nutzung und die Isolation von Sourcecode sowie Branching und Merging liegt außerhalb des Bereichs dieses Artikels. Wir empfehlen Ihnen tfsbranchingguideiii.codeplex.com für entsprechende Informationen, die in künftigen Anleitungen enthalten sein werden.

Team Project-Archivierungsstrategien

Die regelmäßige Wartung ist sehr wichtig, da eine TFS-Umgebung nie auf unbegrenzten physischen Ressourcen installiert werden kann. Administratoren müssen die regelmäßige Wartung planen, um Daten abgeschlossener Projekte zu archivieren und den Server zu entlasten, bevor diese Auslastung zu Leistungsproblemen für Entwicklungsteams führt.

Die Rangers Upgrade Guidance (vs2010upgradeguide.codeplex.com) definiert eine Reihe möglicher Strategien im Rahmen der Aktualisierungsanleitung, ähnlich der Prozedur, die von den Microsoft Consulting Services entwickelt wurde (vgl. Abb. 5):

Abb. 5 Mögliche Archivierungsstrategie

1. beginnen Sie mit einer Kopie der Team Project Collection.
2. Löschen Sie aktive Team Projects aus der neu geklonten Archiv-Team Project Collection (mit dem Befehlszeilenutility TFSDeleteProject).
3. Löschen Sie die aktiven Projekte aus der ursprünglichen (aktiven) Team Project Collection.
4. Die neue Team Project Collection kann dann auf externen Medien gespeichert werden, wie etwa auf Band oder Flashmedien, und dann von der Hardware entfernt werden. Wenn das System überprüft wird, können die Archivmedien zu diesem Zweck einfach wiederhergestellt werden.
5. Trennen Sie die neue Team Project Collection, um sie später leichter zurückerhalten zu können.

Dies mag trivial klingen, erfordert jedoch eine Richtlinie für die Bestimmung, welche Team Projects archiviert werden können und welche nicht. Achten Sie besonders darauf, dass Sourcecodeverzweigungen vom System entfernt werden, wenn eine TFSDeleteProject-Aktion durchgeführt wird, dies kann nicht rückgängig gemacht werden.

Folgendes wird für eine Archivierungsrichtlinie empfohlen:

• Richten Sie eine Projektabschlussrichtlinie für Entwicklungsteams ein, um Projektdaten zu bereinigen und zu speichern. Sourcecode ist nicht das einzige Material, das gespeichert werden muss. Projektanforderungen sind interessant, liegen aber wahrscheinlich nicht in einem Format vor, das die Wiederverwendung oder die Verbesserung erlaubt. Funktionale Spezifikationen müssen mit vorherigen zusammengeführt werden, um den aktuellen Zustand des Produkts zum Zeitpunkt des Projektabschlusses wiederzugeben. Die Anforderungen für jenes Projekt können dann archiviert werden, ohne dass Datenverlust befürchtet werden muss. Arbeitselemente können nicht von einem Team Project in ein anderes übernommen werden wie Sourcecode, sie müssen also entscheiden, wie abgeschlossene Arbeitselemente nach einem Projekt gespeichert werden sollen.
• Benachrichtigen Sie alle Teams über eine anstehende Archivierung, bevor diese stattfindet und führen Sie dabei alle zur Archivierung vorgesehenen Team Projects auf.
• Richten Sie in jedem Team Project einen Meilenstein ein, der als Container für die finalen Projektdaten einer Projektinitiative dient, einschließlich von Anforderungslisten, Projektabschlussberichten sowie aller Dokumentation, die für den Projektabschluss unter normalen Methodologierichtlinien gespeichert wird.

Alle Projektdaten – nicht nur der Sourcecode – müssen aufbewahrt werden, damit ein Archiv seinen Zweck erfüllt.

Die Aufteilung von Team Project Collections ist erforderlich, um auf die mögliche Aufteilung eines Geschäftsbereichs in zwei oder mehrere Einheiten reagieren zu können. In diesem Szenario wird ähnlich wie bei der Archivierung von Team Projects vorgegangen, obwohl keines der Team Projects archiviert wird. Die zweite Team Project Collection wird wie die ursprüngliche behandelt, insofern sie jetzt regelmäßig gewartet werden muss, und zwar unabhängig von der ursprünglichen Team Project Collection.

Die Verschiebung von Team Projects zwischen Team Project Collections ist nicht einfach, und sobald eine Sammlung aufgeteilt ist, kann sie nicht wieder zusammengeführt werden, da einer Sammlung nur Team Projects hinzugefügt werden können. Für die Zusammenführung von Team Project Collections ist angep. Code mit dem TFS API erforderlich, um Projektdaten von einer Sammlung in eine andere zu kopieren.

 Obwohl nicht empfohlen, können Sie mit den TFS Integration Tools Team Projects zu Team Project Collections zusammenführen – vgl. die Dokumentation zu den TFS Integration Tools (bit.ly/9tHWdG).

In einem künftigen Artikel werden wir untersuchen, wie die Ranger die Herausforderungen des Managements verteilter agiler Teams mit Visual Studio ALm überwinden.

Willy-Peter Schaub ist Senior Program Manager bei den Visual Studio ALM Rangers im Microsoft Canada Development Center. Seit Mitte der 1980-er Jahre bemüht er sich um mehr Einfachheit und Verwaltbarkeit in der Softwareentwicklung. Sie finden seinen Blog unter blogs.msdn.com/b/willy-peter_schaub, oder folgen Sie ihm auf Twitter unter twitter.com/wpschaub.

Mike Schimmel ist ALM-Lösungsarchitekt bei den Microsoft Consulting Services U.S. Architects und zentrales Mitglied der Visual Studio ALM Rangers. Er verfügt über beinahe 25 Jahre Erfahrung mit ALM, von Forschung und Beratung bis hin zu Produktvertrieb und Servicebereitstellung.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Bill Essary, Bill Heys,Martin Hinshelwood,Bijan Javidi und Mario Rodriguez