TFS 2012 Versionskontrolle: Grundlagen, Check-In Policies und Branch-Modelle

Von Tobias Richling

Die Versionskontrolle ist in vielen Fällen das Erste, womit ein Nutzer des Team Foundation Servers in Kontakt gerät, obwohl sie im laufenden Entwicklungsprozess nicht den Anfang darstellt. Der Themenbereich Versionskontrolle beginnt mit grundlegenden Dingen wie Ein- und Auschecken von Dateien, erweitert sich aber schnell auf Branch-Pläne, die sich wiederum eng mit der Situation des Nutzers verbinden, zum Beispiel durch die Art und Weise, wie Releases erstellt, versioniert und verwaltet werden.
In diesem shortcut werden gängige Branch-Konzepte skizziert, die neuen Features des Kontextwechsels und Code Review demonstriert und vorhandene Check-in Policies und deren Einsatzmöglichkeiten vorgestellt. Außerdem geht es um Shelvesets und deren Gebrauch, Check-in Policies und die Technik, Work Items beim Merge mit zu übertragen. Beim Leser dieses shortcuts werden lediglich ein grundlegendes Verständnis von Versionskontrolle und eine vorhandene TFS-Installation mit angelegtem Teamprojekt vorausgesetzt.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 15. Dez. 2012
• ISBN: 9783868024364

Buchvorschau

Tobias Richling, Michael Klei

TFS 2012 Versionskontrolle

Grundlagen, Check-In Policies und Branch-Modelle

ISBN: 978-3-86802-436-4

© 2012 entwickler.press

Ein Imprint der Software & Support Media GmbH

1 Einleitung

Die Versionskontrolle ist in vielen Fällen das Erste, womit ein Nutzer des Team Foundation Servers in Kontakt gerät, obwohl sie im laufenden Entwicklungsprozess nicht den Anfang darstellt. Der Themenbereich „Versionskontrolle" beginnt mit grundlegenden Dingen wie Ein- und Auschecken von Dateien, erweitert sich aber schnell auf Branch-Pläne, die sich wiederum eng mit der Situation des Nutzers verbinden, zum Beispiel durch die Art und Weise, wie Releases erstellt, versioniert und verwaltet werden.

In diesem shortcut

werden gängige Branch-Konzepte skizziert

werden die neuen Features des Kontextwechsels und Code Review demonstriert

werden Shelvesets und deren Gebrauch erläutert

werden vorhandene Check-in Policies und deren Einsatzmöglichkeiten vorgestellt

werden eigene Check-in Policies entwickelt

wird eine Methode vorgestellt, Work Items beim Merge mit zu übertragen

Voraussetzungen für das Lesen dieses shortcuts

eine vorhandene TFS-Installation mit angelegten Teamprojekt

Grundlegendes Verständnis von Versionskontrolle

2 Grundlagen der Versionskontrolle

Bevor anhand eines durchgehenden Szenarios der alltägliche Umgang mit der Versionskontrolle gezeigt wird, sind ein paar nicht ganz alltägliche Aufgaben dran: Eine Lösung, sei sie neu oder bereits vorhanden, soll in die Versionskontrolle gebracht werden. Hierzu sind ein paar Schritte und Grundlagen notwendig, die im Folgenden vermittelt werden.

Wenn Sie den TFS bereits genutzt haben und mehr an den neuen Features interessiert sind, können Sie diesen Absatz überspringen.

Als Beispiel wird eine Intranetanwendung erstellt und in die Versionskontrolle gebracht. Gedanklich handelt es sich dabei um eine Anwendung, in der Meetings erfasst werden können. Es geht hier allerdings nicht um die Implementierung dieser Anwendung, sondern um das Arbeiten mit der Versionskontrolle.

2.1 Ein Teamprojekt anlegen

Nach einer Neuinstallation des TFS existiert bereits eine Teamprojekt-Collection, die aber noch keine Teamprojekte enthält. Die Collection wird im TFS durch eine eigene Datenbank abgebildet und ist die höchste Abstraktionsebene. Die eigentliche Entwicklung eines Produkts findet in einem Teamprojekt statt.

Die Anlage eines Teamprojekts erfolgt im Visual Studio. Bevor es losgeht, muss man sich zunächst mit dem gewünschten Server verbinden. Wie alle Arbeiten im Zusammenhang mit dem TFS im Visual Studio, beginnt der Tag im Team Explorer, den man über den Menüpunkt View | Team Explorer einblenden kann. Unterhalb der Symbolleiste wird angezeigt, in welchem Bereich man sich befindet, beim Starten ist das Home. Klickt man auf den Pfeil an der rechten Seite, kann man über das Menü Projects and Teams | Connect to Team Project eine Verbindung zu einem TFS erstellen.

Dazu klickt man im Dialog Connect to a Team Foundation Server auf den Button Servers… und dort auf den Button Add…. Es öffnet sich der Dialog aus Abbildung 2.1.

Abbildung 2.1: Verbindung zum TFS herstellen

Im Feld für den URL trägt man den Computernamen des Servers ein, die restlichen Einstellungen kann man, eine Standardinstallation vorausgesetzt, unverändert lassen. Im Feld Preview wird der vollständige URL angezeigt. Wenn man alle Dialoge bestätigt, wird eine Verbindung zu dem gewünschten Server hergestellt.

Zurück im Team Explorer, kann man über den Link Create a New Team Project ein neues Teamprojekt anlegen. Hier folgt man einfach dem Assistenten. Das neue Teamprojekt soll den Namen Lab erhalten und das von Microsoft mitgelieferte Scrum Template verwenden. Das Anlegen dauert eine Weile, und danach kann es losgehen!

Sollte bereits ein Teamprojekt existieren, kann man ebenfalls über den Dialog aus Abbildung 2.1 den gewünschten Server auswählen, es werden dann alle Teamprojekt-Collections und deren Teamprojekte angezeigt. Hier wählt man über die Kontrollkästchen einfach die gewünschten Teamprojekte aus.

2.2 Arbeitsbereich anlegen

Die Grundlage zur Arbeit mit der Versionskontrolle stellt der Arbeitsbereich, englisch Workspace dar, dieser ist das Bindeglied zwischen der Versionskontrolle und dem lokalen Rechner des Entwicklers. Der Workspace besitzt einen Namen und verbindet einen Computer und einen Benutzernamen. Bei der Installation wird bereits ein Standard-Workspace angelegt, der für den lokalen Computer und den Installtionsbenutzer gilt. Die Verwaltung der Workspaces kann unter dem Menüpunkt File | Source Control | Advanced | Workspaces… aufgerufen werden (Abbildung 2.2 oben rechts).

Abbildung 2.2: Die Workspace-Verwaltung

Standardmäßig werden alle Arbeitsbereiche des aktuellen Benutzers auf dem aktuellen Computer angezeigt. Über das Kontrollkästchen unten links können auch Arbeitsbereiche auf anderen Computern eingeblendet werden.

Der Arbeitsbereich ist die lokale Spiegelung eines Ausschnitts der gesamten Versionskontrolle. Die meisten Bearbeitungsaktionen werden zunächst lokal ausgeführt und sind noch nicht direkt wieder in der Versionskontrolle sichtbar. Änderungen von Dateien führen dazu, dass diese ausgecheckt werden. Abhängig von der Konfiguration kann das zu einer Sperrung der Datei führen (pessimistisches Locking) oder auch nicht (optimitisches Locking) – in letzterem Fall kann die gleiche Datei von mehreren Nutzern verändert werden. Die Änderungen werden später bei einem Check-in wieder mit der Versionskontrolle abgeglichen. Außerdem kann der Benutzer jederzeit den aktuellen oder einen älteren Stand aus der Versionskontrolle abrufen.

Lokale Ordner zuweisen

Der zentrale Punkt eines Arbeitsbereichs ist die Abbildung der Versionskontrollpfade auf lokale Pfade des Dateisystems. Dieses Mapping kann definiert werden, indem der betroffene Arbeitsbereich ausgewählt und der Edit-Knopf gedrückt wird. Es erscheint der Dialog aus Abbildung 2.2, rechts unten (hier mit den erweiterten Eigenschafen). Im unteren Bereich befindet sich die Sektion Working Folders. Hier wird ein Versionskontrollordner, die Pfade beginnen mit $ und werden durch Slashes getrennt, auf einen Dateisystemordner abgebildet. Es sind mehrere Zuordnungen möglich. Damit können unterschiedliche Teilbereiche des Servers auf nicht zusammenhängende Ordner abgebildet werden. Es ist aber aufgrund der Übersichtlichkeit ratsam, wie in der Abbildung, ein gemeinsames Basisverzeichnis zu wählen und alle Teile der Versionskontrolle in einer dem Server angepassten Ordnerstruktur abzurufen.

Berechtigungen

Jeder Ordner auf der lokalen Festplatte kann standardmäßig gleichzeitig nur zu einem Workspace, und somit zu einem Benutzer gehören. Es ist also nicht möglich, dass sich zwei Benutzer auf dem gleichen Rechner einen Ordner teilen.

Hinweis: Standardmäßig kann jeder Ordner auf der lokalen Festplatte gleichzeitig nur einem Arbeitsbereich zugewiesen sein.

Es gibt diverse Szenarien, in denen diese Beschränkung hinderlich ist, zum Beispiel, wenn es einen Rechner gibt, auf dem mehrere Entwickler arbeiten, um Fehler zu finden und zu beheben. Hier bieten öffentliche Arbeitsbereiche eine Lösung. Die entsprechende Einstellung befindet sich im Kombinationsfeld Permissions. Durch die Einstellung Public Workspace kann definiert werden, dass mehrere Benutzer diesen Arbeitsbereich verwenden können.

Lokale Arbeitsbereiche

Das Konzept der Workspaces gibt es bereits seit den