Mittwoch, 23. Mai 2012


Artikel

März 2008 | Artikel

VSTS im Einsatz: Sourcen im Griff

(Link zum Artikel: http://www.entwickler.de/dotnet//001607)

Teil 2: Mit Quelltextverwaltung und Daily Build die Qualität des Quellcodes sichern

Text: Thomas Janssen und Markus Schiller
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share
Im ersten Teil dieses Artikels werden alle erforderlichen Schritte beschrieben, um nach der Anlage eines neuen Teamprojekts mit der Entwicklung von Code zu beginnen. Zusätzlich werden die im Alltag wichtigsten Funktionalitäten der Quelltextverwaltung Team Foundation Source Control vorgestellt. Der zweite Teil zeigt die Möglichkeiten von MSBuild und Team Build zur Realisierung eines Daily Build. Es wird gezeigt, wie mit Team System ein voll automatisierter Build-Prozess aufgesetzt wird.
Teil 1   Teil 2   Teil 3   Teil 4   

Nach dem Anlegen eines neuen Teamprojektes mithilfe des Project Creation Wizards kann mit der Arbeit am neuen Projekt begonnen werden. Für die Verwaltung der Sourcen steht dabei der Source Control Explorer zur Verfügung – zu sehen in Abbildung 1. Ähnlich konzipiert wie sein „großes” Vorbild, der Windows Explorer, zeigt er zum einen die Struktur der Teamprojekte und Verzeichnisse innerhalb der Source Control des Team Foundation Servers, zum anderen gibt er Auskunft darüber, ob der Anwender über die neueste Version einer Datei oder eines Verzeichnisses verfügt. Aufgerufen wird der Source Control Explorer über den „Source-Control“- Link eines jeden Teamprojektes innerhalb des Team Explorers – im übrigen das am meisten genutzte Fenster im Umgang mit Teamprojekten.

Die Rolle der Workspaces

Das wichtigste Element in der Symbolleiste des Source Control Explorers ist die Anzeige des ausgewählten Workspaces. Ein Workspace definiert, welche Verzeichnisse aus der Source Control in ein entsprechendes Arbeitsverzeichnis kopiert werden und wo genau sich dieses Arbeitsverzeichnis befindet. Jeder Anwender darf sich eine beliebige Anzahl an Workspaces erstellen, jedoch geht bei einer hohen Anzahl schnell die Übersicht verloren. In der Praxis hat es sich als sinnvoll erwiesen, neben einem Workspace mit der aktuellsten Entwicklungsversion einen zweiten mit dem Stand der letzten Release-Version zu haben. Dies erlaubt das schnelle Wechseln des Arbeitsfokus von der Entwicklung neuer Features zum Fixen eines Bugs in der alten Version, ohne sich dabei um das Speichern noch nicht eingecheckter Änderungen kümmern zu müssen. Zum Wechseln des Workspaces muss dann lediglich noch der Name des gewünschten Workspaces im Dropdown-Menü der Symbolleiste geändert werden.

Nach dem Anlegen eines neuen Teamprojekts wird es im Source Control Explorer in grauer Schrift dargestellt. Dies ist ein Hinweis dafür, dass im aktuell ausgewählten Workspace noch nicht definiert wurde, in welches Arbeitsverzeichnis die zukünftigen Daten des Projektes kopiert werden sollen. Das sog. Mapping zwischen dem auf dem Server liegendem Teamprojekt und dem Arbeitsverzeichnis des Anwenders kann in einen Workspace hinzugefügt oder es kann ein neuer Workspace hierfür angelegt werden.

Erzeugt und bearbeitet werden Workspaces über den letzten Eintrag im Dropdown-Menü des Source Control Explorers. Über diesen und einen weiteren Dialog gelangt man zum Fenster Add Workspace (Abbildung 2). Hier erhält der neue Workspace einen Namen und einen Kommentar zur genaueren Beschreibung seines zukünftigen Inhalts. In der Tabelle Working folders wird das Mapping zwischen Verzeichnissen des Teamprojektes und dem Arbeitsverzeichnis hergestellt. Dabei ist es möglich, sich bestimmte Verzeichnisse aus einem oder auch verschiedenen Teamprojekten in einem Workspace zusammenzustellen oder auch komplette Teamprojekte auszuwählen (Abbildung 2):

Nach dem Anlegen des neuen Workspaces muss dieser noch im Dropdown-Menü des Source Control Explorers ausgewählt werden, da dies nicht automatisch geschieht. Danach erscheint das neu angelegte Teamprojekt noch so lange in grauer Schrift, bis über die Symbolleiste ein Get Latest Version durchgeführt wird. Für die Auswahl eines bestimmten Versionsstandes stehen mit Get Specific Version… insgesamt vier verschiedene Kriterien zur Auswahl: Datum, Changeset, Label und Workspace Version.

Der Import von bereits vorhandenem Quellcode

Es kommt sicher öfter vor, dass schon vor dem Anlegen des eigentlichen Teamprojekts die ersten Zeilen der neuen Software geschrieben sind. In diesem Fall können die Dateien entweder in das Arbeitsverzeichnis des Workspaces kopiert werden oder auch ein Workspace auf das Verzeichnis der bereits bestehenden Software gemappt werden. Über Add Files, das man in der Symbolleiste des Source Control Explorers findet, können ganze Verzeichnisstrukturen importiert werden (Abbildung 3).

Der abgebildete Dialog Add to Source Control erlaubt die Eingabe von Dateitypen, die nicht in die Source Control importiert werden dürfen. Zu sehen ist außerdem, wie die Auswahl der Dateien mithilfe der Check-Boxen noch von Hand beeinflusst werden kann.

Codieren im Schwebezustand – die Pending Changes

Nachdem die für das Projekt notwendigen Dateien für das neue Teamprojekt identifiziert sind, müssen sie noch eingecheckt werden. So lange dies nicht geschehen ist, werden diese mit einem gelben Plus im Source Control Explorer versehen. In Team System bekommt jede Datei, die verändert wird, ein eigenes Symbol, das ihren Zustand verdeutlicht. Neben ausgecheckten und hinzugefügten Dateien gilt dies auch für Dateien, die umbenannt, gebranched, gemerged, verschoben, ja sogar gelöscht wurden. Dies zeigt dem Anwender den aktuellen Zustand, in dem sich die Dateien seines Projektes gegenüber der Quelltextverwaltung befinden. (...)

Teil 1   Teil 2   Teil 3   Teil 4   

Kommentare