VSTS im Einsatz: Sourcen im Griff

(…) Auscheckens anfreunden
kann, der sei beruhigt. Zum einen lässt
sich der Standard-Lock-Type auf Check
Out
setzen, zum anderen lässt sich das
gleichzeitige Auschecken für das gesamte
Teamprojekt abschalten.

Neu bei VSTS – Shelving

Die Serie der Neuerungen im Team System
Source Control reißt nicht ab. Ein bisher
einzigartiges Konzept wurde mit Shelving
realisiert. Shelving erlaubt es, solche
Änderungen, die entweder noch nicht reif
genug, verfrüht oder nur mögliche Alternativen
darstellen, dauerhaft in Source
Control zu speichern, ohne dabei den restlichen
Code zu gefährden oder Check-In-
Policies fürchten zu müssen. Shelvesets unterscheiden
sich von ihren Geschwistern,
den Changesets, nur in zwei Punkten: Statt
einer ID werden sie durch einen Namen
gekennzeichnet und sie werden in einem
separaten Bereich der Source Control gespeichert.
Shelvesets stehen auch anderen
Usern zur Verfügung. Diese können sich
die gespeicherten Änderungen in ihren
eigenen Workspace laden und diese verwenden
oder z.B. ein Review durchführen.
Shelving sollte jedoch nicht verwendet
werden, um in Zukunft nicht mehr
regelmäßig einzuchecken zu müssen. Im
Dialog Pending Changes befinden sich
neben der Schaltfläche zum Check-In
zwei weitere für das Shelven bzw. Unshelven
von Shelvesets.

Branching/Merging

Vor allem Source-Safe-Nutzer mieden dieses
Thema in der Vergangenheit wie der
Teufel das Weihwasser. Diese Zeiten sind
mit Team System zum Glück Geschichte.
Hier noch mal das wichtigste für alle „Bekehrten“:
Durch das Erstellen von Branches,
also parallelen Codesträngen, wird
das parallele Arbeiten an verschiedenen
Versionen ermöglicht. Als Merge bezeichnet
man den Vorgang, wenn ein ganzer
Branch oder auch ein Teil von ihm wieder
mit seinem ursprünglichen Codestrang
vereinigt wird.

Das Team Foundation Source Control
verfügt über einen verzeichnisbasierten
Branch-Mechanismus, was bedeutet,
dass statt einzelnen Dateien besser ganze
Verzeichnisse gebranched werden. Ein gebranchtes
Verzeichnis erscheint im Source
Control Explorer wie eine Kopie seines
Ursprungsverzeichnisses, jedoch unter
einem neuen Namen. Der Branch kann
wie jedes andere Verzeichnis auch beliebig
verschoben werden, Source Control merkt
sich jedoch die Beziehung der beiden Verzeichnisse
genau. Das Bemerkenswerte an
Source Control ist, dass zwischen diesen
beiden Verzeichnissen einzelne Changesets
gemerged werden können, was bedeutet,
dass z.B. ein Bugfix innerhalb des einen
Zweigs elegant in den zweiten einfließen
kann, ohne dies von Hand tun zu müssen.
Dieses Vorgehen wird auch als Cherry Picking
bezeichnet, da man nur ausgewählte
Änderungen zwischen den „Zweigen“
propagiert.

Je nach Belieben ist es mit Team Foundation
Source Control ein Leichtes, ein
Branching-Modell wie Branch by Release,
Branch by Purpose
oder Mainline zu verfolgen,
bei dem immer zu ganz bestimmten
Zeitpunkten oder zu einem ganz bestimmten
Zweck ein Branch oder Merge vorgenommen
wird [5]. Die Bestimmung der
Version, auf der ein Branch gebildet wird,
kann auf verschiedene Weisen geschehen.
Neben der aktuellen Version kann auch
ein Changeset als Basis verwendet werden
– ein bestimmtes Datum, ein Label aber
auch die Version eines bestimmten Workspaces
kann als Grundlage für einen Branch
verwendet werden.

Ein Diagramm zur Darstellung des Versionsbaumes,
wie in vielen anderen Quelltextverwaltungen
üblich, gibt es in Source
Control jedoch leider noch nicht.

Die Power Tools schließen Lücken

Da es der Source Control zum Zeitpunkt
der Auslieferung von Team System 2005
an der einen oder anderen Stelle noch an
Funktionalität gefehlt hat, wird diese in unregelmäßigen
Abständen kostenlos nachgeliefert
[4]. Bekannt als Power Tools integrieren
sie sich zwischen die schon vorhandenen
Einträge in die Menüs des Systems
und stellen von dort aus ihre Dienste
zur Verfügung. Als auffälligste Vertreter
der Power Tools sind TreeDiff und Annotate
zu nennen. TreeDiff, wie es der Name
schon vermuten lässt, ist ein Add-in zum
Vergleichen von Verzeichnisstrukturen.
Das schöne dabei ist, dass es völlig frei
steht, welche Versionen und welche Quellen
miteinander verglichen werden. Wie
bei den Branches kann auch hier mit einer
Vielzahl an Kriterien entschieden werden,
welche Unterschiede zu berechnen sind.

Hinter Annotate verbirgt sich eine weitere
Innovation. Mit Annotate ist es möglich
anzuzeigen, mit welchem Changeset
welche Zeile einer Codedatei das letzte
Mal verändert wurde. Dieses Feature vereinfacht
beispielsweise die Fehlersuche innerhalb
einer Datei, wenn bekannt ist, mit
welchem Changeset der Fehler in das System
gekommen ist. Neben der Changeset-
ID, die den direkten Zugriff auf die Changeset-
Details erlaubt (Abbildung 4), werden
ebenfalls Datum und User eingeblendet. In
der neuesten Version der Power Tools werden
auch eine Reihe weiterer Check-In-Policies
angeboten.

Team Foundation Sidekicks

Neben den Power Tools, die sich direkt in
die IDE integrieren, gibt es noch weitere
Tools die das Arbeiten und vor allem auch
das Administrieren des Team Foundation
Servers erleichtern. Die Team Foundation
Sidekicks
ergänzen und erweitern die in
Team System existierende Funktionalität
stellenweise erheblich. Durch ihre Tabellendarstellungen
erleichtern sie es, sich einen
Überblick über Workspaces, Dateiänderungen,
die Historie von Verzeichnissen
und Dateien, Branches, Merges und Labels
zu verschaffen. Die Team Foundation Sidekicks
sind ebenfalls kostenlos und können
unter [3] heruntergeladen werden. Nachdem
nun die Neuerungen für das Verwalten
des Codes ausgiebig durchleuchtet wurden,
geht es im Weiteren um den nächsten
logischen Schritt, das Verwenden der Sourcen,
um daraus eine einsatzfähige Software
zu bauen.

Unseren Daily Build gib uns heute – der Team Build

Neben einer neuen Quelltextverwaltung
beinhaltet der Visual Studio Team Foundation
Server auch die Funktionalität eines
Team Builds (siehe Abbildung 6). Ein Team
Build erlaubt es einen Prozess zu definieren,
der alle nötigen Schritte zum Bauen des
gesamten Endprodukts enthält. Der Build-
Prozess nimmt im Zusammenspiel mit der
Quelltextverwaltung, Aufgabenlisten, Bugtracking
und Unit Test eine zentrale Rolle
ein. Als Daily Build überprüft er beispielsweise
durch das Übersetzen und Ausführen
der Unit Tests regelmäßig die Qualität der
Quelltexte im Projekt und speist die so gefundenen
Metriken, wie etwa fehlgeschlagene
Unit Tests und Bugs, die noch nicht
durch Tests abgedeckt sind, in das Data
Warehouse des Team Foundation Server
ein. Der Daily Build fungiert als Motor
und ermöglicht die Qualitätsverfolgung
im Projekt, indem er die Statistiken und
Reports mit verwertbaren Daten versorgt.
Es empfiehlt sich, bereits möglichst früh im
Projekt einen Daily Build aufzusetzen, um
schon von Begin an über eine aussagekräftige
Qualitätskontrolle zu verfügen.

Abb. 6: Team Builds in Visual Studio

Die Frequenz mit der Team Builds ausgeführt
werden und deren Ausführlichkeit
beim Validieren des aktuellen Codes können
erheblich variieren, von einfachen Daily
Builds mit sog. Smoke Tests [1] bis hin
zur Continuous Integration [2]. Grundlegend
ist dabei immer das Kompilieren
aller Sourcen in ihrer neuesten Version.
Hierbei werden die aktuellen Sourcen aus
der Quelltextverwaltung geholt und übersetzt,
um so die Integrierbarkeit neuer Programmteile
zu gewährleisten und auch die
Funktionalität bereits bestehenden Codes
abzusichern. Da das gemeinsame Übersetzen
aller Quelltextdateien insgesamt
wenig Aussagekraft über die tatsächliche
Qualität ergibt, spricht man hier von einem
Smoke Test, bei dem im schlimmsten Fall
eben Rauch aufsteigt, d.h. ein Fehler durch
den Compiler geliefert wird. Durch diese
Build-Typen wird bereits ein Mindestmaß
an Qualität der Sourcen sichergestellt.

Am anderen Ende der Skala stehen die
Continuous Integration Builds, bei denen
mit jedem Check-In in die Quelltextverwaltung
ein vollständiges Neuübersetzen
aller Quellen und auch eine Auswahl
besonders wichtiger Unit Tests gestartet
werden. Dieser Build-Prozess erlaubt es
nach kurzer Zeit eine Aussage darüber zu
treffen, ob sich die Qualität der Software
mit dem letzten Check-In verschlechtert
hat, nämlich dann, wenn dieser wiederholte
Build fehlschlägt oder Unit Tests nicht
bestanden werden. Durch Continuous Integration
ist es möglich, innerhalb kurzer
Zeit auf eingeschlichene Fehler zu reagieren
und diese umgehend zu beheben.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.