© DrHitch/Shutterstock.com
TFS 2012 Team Build

3 Arbeiten mit Team Builds


Das Herzstück der Arbeit mit Team Builds bildet die Build-Definition. Hier werden der dem Build zugrunde liegende Prozess sowie alle benötigten Parameter festgelegt. Ausgehend von der Build-Definition können dann Builds ausgeführt und überwacht werden. Die Ergebnisse der Builds werden gemäß den Vorgaben der Definition vorgehalten oder gelöscht. Zentrales Instrument zur Verwaltung von Builds ist der Bereich Builds des Team Explorers.

3.1 Build-Definition anlegen

Bevor ein Build ausgeführt werden kann, muss definiert werden, was gebaut werden soll und wie das zu geschehen hat. Hierzu wird eine Build-Definition angelegt, aus der dann später Build-Anforderungen generiert werden können. Die Build-Anforderung wird vom Controller verarbeitet, und der Build wird gemäß den Vorgaben in der Build-Definition ausgeführt. Um eine neue Build-Definition anzulegen, klickt man im Build-Bereich des Team Explorers auf den Link New Build Definition. Daraufhin öffnet sich im Hauptbereich ein neues Dokument, in dem man schrittweise alle Parameter eintragen muss (Abbildung 3.1).

3_1_BuildDefintion-Create-General.png

Abbildung 3.1: Eine neue Build-Definition anlegen

General

Hier werden allgemeine Einstellungen vorgenommen, insbesondere wird hier der Name der Build-Definition festgelegt. Da dieser Name später häufig wieder auftaucht, ist ein sinnvoller Name zu empfehlen. Es hat sich bewährt, den Namen der Quellcodelinie, auf der der Build basiert, in den Namen aufzunehmen. Außerdem kann die Build-Frequenz, etwa nächtlich oder Continuous Integration (CI), mit in den Namen aufgenommen werden. Der Beschreibungstext kann hilfreich sein, um Besonderheiten des Builds zu beschreiben, zum Beispiel, ob Dokumentationen generiert oder bestimmte Server aktualisiert werden.

Die Optionen im unteren Bereich steuern, wie Build-Anfragen für diese Definition behandelt werden. Das normale Verhalten ist, dass eine Build-Anfrage zunächst in eine Warteschlange eingestellt wird. Der Build-Controller arbeitet diese Warteschlange ab und weißt die Builds gemäß ihrer Reihenfolge und Priorität einem Build-Agent zu. Dieses Verhalten entspricht der Einstellung Enabled. Die Einstellung Paused sorgt dafür, dass Anfragen für einen Build in die Warteschlange gestellt, aber nicht automatisch gestartet werden. Das ist hilfreich, wenn ein Administrator die durchzuführenden Builds freigeben soll. Die Einstellung Disabled sorgt dafür, dass für diese Build-Definition keine Build-Anfragen mehr in die Warteschlange gestellt und gestartet werden können. Die gewählte Einstellung wird am Icon der Build-Definition durch ein entsprechendes Zusatzsymbol kenntlich gemacht.

Trigger

Hier wird festgelegt, wodurch der Build ausgelöst wird. Die einzelnen Optionen wurden im Abschnitt 2.3 bereits erläutert, sind in Tabelle 3.1 aber nochmals kurz zusammengefasst.

3_1_Tabelle.png

Tabelle 3.1: Mögliche Trigger zum Auslösen eines Builds

Workspace

Jeder Build basiert auf einem Workspace. Die Definition des Workspace wird vom Agent verwendet, um die betroffenen Zweige aus der Quellcodeverwaltung abzurufen. Die Einrichtung des Workspace erfolgt analog zur Einrichtung eines Workspace für einen Entwickler. So kann als Vorlage für den Build-Workspace ein vorhandener Workspace kopiert werden.

Für den Workspace können Quellcodeverwaltungspfade ausgewählt und auf lokale Pfade des Agents abgebildet werden. Für den lokalen Pfad des Agents kann die Build-Variable $(SourceDir) als Platzhalter für das Basisverzeichnis des Agents verwendet werden, der den Build ausführt. Dieser kann in den Eigenschaften des Build Agents definiert werden, wie in Abschnitt 3.1 beschrieben.

Es ist möglich, in dem Workspace mehrere Quellcodepfade einzutragen. Es ist jedoch eine gute Praxis, einen Build auf einer kompletten Codelinie, also einem konkreten Branch, aufzusetzen. Ein Branch stellt eine abgeschlossene Einheit dar, die in sich vollständig sein sollte. Wenn man sich an diese Regel hält, bleibt der Workspace übersichtlich und einfach zu verstehen.

Build Defaults

Hier wird festgelegt, welcher Build Controller für diesen Build zuständig ist. Durch die Auswahl des Controllers wird implizit festgelegt, welche Build Agents den Build später durchführen können, da sie dem Build Controller unterstellt sind.

Über die Einstellung Staging Location wird festgelegt, ob und wenn ja, an welchem Ort die Build-Ergebnisse, also die kompilierten Assemblies, abgelegt werden. Sollen die Assemblies in einen Ausgabeordner (Drop Folder) kopiert werden, muss dieser in Form eines UNC-Pfads angegeben werden. Es ist darauf zu achten, dass der Benutzer, unter dem die Build-Dienste aufgeführt werden, ausreichende Zugriffsrechte auf die Freigabe besitzt.

Process

Diese Einstellungen bieten die meisten Variationsmöglichkeiten und erlauben es, sowohl den Ablauf des Builds in Form der zu verwendenden Workflow-Definition als auch aller für den Workflow notwendigen Parameter festzulegen.

Die Parameter sind zahlreich, und die sich draus ergebenden Kombinationsmöglichkeiten vielfältig, daher werden sie in Abschnitt 3.4 ausführlich erläutert. Im ersten Schritt muss lediglich der erforderliche Parameter Items to build gesetzt werden. Hier wählt man eine oder mehrere Solutions aus, die im Rahmen des Builds kompiliert werden sollen.

Retention Policy

Über die Retetion Policy wird zu guter Letzt bestimmt, wie lange die Ergebnisse der Build-Durchläufe aufbewahrt werden. Diese Einstellungen können für private und getriggerte Builds separat festgelegt werden. Abhängig vom Ausgang des Builds kann angegeben werden, wie viele vergangene Builds aufbewahrt werden und was von alten Builds gelöscht werden soll, wenn die entsprechende Anzahl erreicht ist (Abbildung 3.2).

3_2_BuildDefintion-Create-RetentionPolicy.png

Abbildung 3.2: Retention Policy einer Build-Definition

Als mögliche Build-Ergebnisse stehen Stopped, Failed, Partialy Succeeded und Succeeded zur Auswahl. Ein Build gilt als Paritaly Succeeded, wenn die Kompilierung selbst erfolgreich war, aber zum Beispiel ein Test fehlgeschlagen ist. Es kann jeweils definiert werden, wie viele alte Builds verwahrt werden sollen. Zur Auswahl steht die Option Keep All, damit werden niemals alte Builds gelöscht. Alternativ kann man eine zu definierende Anzahl von Builds behalten. Einige Vorschlagswerte im Bereich von einem bis zu zehn Builds sind vordefiniert, und wenn das nicht ausreicht, kann eine beliebige Zahl angegeben werden. Wird ein alter Build durch die Retention Policy gelöscht, werden die in der TFS Datenbank gespeicherten Details zu diesem Build immer gelöscht (im Fall einer Installation, die das Data Warehouse mit einschließt, bleiben die Informationen im Warehouse natürlich erhalten). Darüber hinaus kann ausgewählt werden, welche Informationen gelöscht werden sollen. Die Option Drop löscht die kompilierten Assemblies, die in die Netzwerkfreigabe der Drop Location kopiert worden sind. Außerdem kann man Testergebnisse der automatisierten Unit Tests löschen. Bei jedem Build setzt der TFS in allen Quellcodes ein Label, damit der kompilierte Codestand leicht wiedergefunden werden kann. Dieses Label kann über die gleichnamige Option ebenfalls gelöscht werden. Die Option Symbols erlaubt es, die während der Kompilierung möglicherweise in einen Netzwerkpfad veröffentlichten .pdb-Dateien zu löschen.

3.2 Einen Build ausführen

Sobald man eine Build-Definition angelegt hat, erscheint diese in der Liste aller Build-Definitionen unten im Team Explorer. Über den Kontextmenübefehl Queue New Build wird der Dialog aus Abbildung 3.3 geöffnet.

3_3_BuildDefintion-QueueNewBuild.png

Abbildung 3.3: Einen Team Build starten

Die Build-Definition des zu startenden Builds ist bereits ausgewählt. Mit der Einstellung What do you want to build? wird bestimmt, ob es sich um einen öffentlichen Build auf Grundlage des letzten Stands der Quellcodeverwaltung handelt (Einstellung Latest sources) oder um einen private Build (Einstellung Latest sources with shelveset). In diesem Fall muss noch ein Shelveset ausgewählt werden, in dem sich die Änderungen befinden, die zu dem letzten Quellcodestand aus der Versionskontrolle hinzugefügt werden sollen. Im Feld Build Controller ist der Controller eingetragen, der bei der Anlage der Build Definition ausgewählt wurde. Über das Feld Priority in queue kann die Wichtigkeit dieser Build-Anfrage definiert werden. Der Build-Controller arbeitet eingehende Anfragen nach Priorität geordnet ab. Die aktuelle Warteschlangenposition wird im Feld Position angezeigt. Im Feld Drop folder for this build kann ein von der Build-Definition abweichender UNC-Pfad für die kompilierten Dateien des Builds angegeben werden.

Der Reiter Parameters erlaubt die Festlegung bestimmter Workflow-Parameter für diesen konkreten Build-Durchlauf. Die meisten Parameter werden bereits in der B...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang