(...) 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.
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.
