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

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!