(...) Visual Studio bietet die Möglichkeit zur Umsetzung solcher Prozesse. Die Grundlage dafür liefert MSBuild, das seit Visual Studio 2005 das Format aller .NET-Projekte darstellt. Allerdings war das Einrichten eines Daily Builds mit MSBuild bisher eine aufwändige und komplizierte Angelegenheit. Nun kann mithilfe von Team System innerhalb von Minuten eine erste, lauffähige Version eines Builds eingerichtet werden.
Technische Voraussetzungen
Doch erst einmal zur erforderlichen Hardware eines Team Builds. Ein eigenständiger Server zur Ausführung der Team Builds ist zwar nicht zwingend erforderlich, auch ein normaler Entwicklungsrechner kann als Build Server dienen. Die Verwendung eines speziellen Build Servers ist sehr sinnvoll, um bei lang laufenden Kompiliervorgängen und Unit Tests nicht die Rechner der Entwickler zu blockieren, da zur Durchführung eines Team Builds doch erhebliche Rechnerressourcen benötigt werden.
Auf dem Build Server wird ein Service installiert, der vom Team Foundation Server Aufträge zum Bauen von Software-Paketen entgegennimmt. Diese Ansteuerung erfolgt über .NET Remoting und erfordert daher entsprechend offene Ports zwischen dem Build Server und dem Team Foundation Server. Weiterhin muss auf dem Build Server ein entsprechendes Verzeichnis eingerichtet werden, in dem der Build Service arbeiten kann. In diesem Verzeichnis erstellt der Build Service nach eigener Systematik eine Hierarchie von Unterverzeichnissen in denen die einzelnen Builds ausgeführt werden. Der Build Service holt sich dazu alle benötigten Quelltexte in dieses Verzeichnis und übersetzt diese lokal auf dem Build Server. Falls zusätzlich die Ausführung von Unit Tests gewünscht wird, muss Visual Studio in der Developer Edition oder Test Edition installiert werden. Nur in diesen Produkten ist die Funktionalität der Microsoft Unit Tests enthalten.
Team Build Wizard
Die initiale Erstellung eines Builds erfolgt komfortabel über einen Wizard in Visual Studio. Folgende Eckdaten müssen hierbei im Wizard eingegeben werden (Abbildung 7): Der Server und das Verzeichnis, in dem der Build erfolgen soll, und ein UNC-Pfad zu einem Netzlaufwerk, auf dem das Ergebnis des Builds abgelegt wird. Hier sollte ein Laufwerk mit entsprechendem Plattenplatz angegeben werden, da bei der Häufigkeit eines Builds erhebliche Datenmengen zu Stande kommen können. Die Angabe der zu erstellenden Visual Studio Solutions erlaubt auch die Auswahl, in welcher Konfiguration und Reihenfolge diese Solutions erstellt werden sollen (Debug/Release). Dies ist vor allem bei untereinander abhängigen Solutions interessant. So kann man z.B. zuerst die Solution eines Frameworks erstellen und dann die einzelnen Produkte, die dieses Framework verwenden. Einschränkend muss erwähnt werden, dass die Ergebnisse aller Solutions in einem einzigen Ausgabeverzeichnis abgelegt werden. Eine nach Solution getrennte Ablage der erzeugten Assemblies ist nicht direkt möglich. Auch kann nur auf der Ebene der Visual Studio Solutions gearbeitet werden. Das direkte Erzeugen etwa von C#-Projekten ist so nicht möglich.
Unit-Test-Integration
Durch die Angabe einer VSMDI-Datei kann eine Testliste mit Unit Tests spezifiziert werden, die nach erfolgreicher Erstellung der Software durchgeführt werden. Die VSMDI-Datei wird innerhalb von Visual Studio als Testlistenverwaltung angezeigt. Hier können Unit Tests nach verschiedenen Gesichtspunkten zu Listen zusammengefasst werden. Das Format der VSMDIDatei liegt momentan leider in zwei unterschiedlichen Formaten vor. Zum einen in der Visual Studio Developer Edition, zum anderen in der Visual Studio Tester Edition. Dies bereitet dann Probleme, wenn Entwickler die Liste der durchzuführenden Tests bearbeiten müssen, z.B. wenn sie einen Test von der Ausführung ausnehmen wollen. Neben Testlisten kann zusätzlich angegeben werden, ob die Durchführung einer statischen Codeanalyse erfolgen soll. Hierbei werden die Einstellungen der einzelnen Projektdateien verwendet.
Ein Team Build Type kann direkt in Visual Studio angestoßen werden, per Kommandozeilentool TFSBuild kann dieser auch als wiederkehrender Task im Betriebssystem angemeldet werden. Das Protokoll und Ergebnis eines Builds stehen in Visual Studio zur Verfügung und können von allen Entwicklern eingesehen werden.
Erweiterbarkeit
Der Build Server ist nicht auf die Ausführung eines bestimmten Builds beschränkt. Es können beliebig viele Build Types erstellt werden. Bei diesen Build Types handelt es sich um MSBuild-Dateien im XMLFormat, die leicht selbst editiert werden können. Mit Team Build stehen neben den gängigen Funktionalitäten des MSBuild, wie dem Übersetzen von C#-Dateien oder Kopieren von Dateien, zusätzliche so genannten Tasks und Targets zur Verfügung. Diese dienen zur Kommunikation mit der Quelltextverwaltung und der WorkItem- Datenbank des Team Foundation Server (siehe SideBox Build Tasks auf MSDN). Diese Tasks können natürlich auch in eigenen MSBuild-Dateien verwendet werden, bzw. ist ein Team Build Type auch durch eigene Tasks erweiterbar.
Der Team Build Wizard erzeugte eine MSBuild XML-Datei TFSBuild.proj und legt diese automatisch in der Quelltextverwaltung ab. Die Weiterbearbeitung eines Build Types erfolgt direkt in dieser Datei, eine Unterstützung in Visual Studio ist hier leider nicht mehr vorhanden.
Die Rolle der Build Results
Das Ergebnis eines Team Builds wird nach der Ausführung des im jeweiligen Build- Protokoll mit der Übersetzung der Quellen und den gegebenenfalls durchgeführten Unit Tests angezeigt. Es lässt sich also jederzeit auf die Ergebnisse früherer Team Builds zurückgreifen. Die Statistik mit erfolgreichen und fehlgeschlagenen Tests, die Code Coverage, d.h. die tatsächliche Abdeckung des eigenen Codes durch Unit Tests, wird im Data Warehouse des Team Foundation Servers eingetragen und steht für Auswertungen in Reports zur Verfügung. Das Protokoll führt hierbei genau Zeitpunkt, Dauer und die vorgenommen Arbeitsschritte auf. Fehler bei der Übersetzung der Quelltexte, fehlgeschlagene und erfolgreiche Unit Tests werden aufgelistet, sowie die Prozentangabe der Code Coverage. Zusätzlich ermittelt der Team Foundation Server auch die Änderungen der Sourcen, die sich aus den Eincheckvorgängen seit dem letzten erfolgreichen Team Build ergeben. Dies und die Liste der erledigten Aufgaben, die mit diesen Eincheckvorgängen verbunden wurden, ergeben ein automatisches Change Log der Änderungen im aktuellen Build. Somit dokumentiert der Team Build nicht nur „wie“ das Projekt gebaut wurde, sondern auch „was“ in diesem Build tatsächlich an Änderungen vorliegt. Diese Info ist sehr nützlich, um das Build- Ergebnis an manuelle Tests weiterzugeben. Dort kann dann gezielt die tatsächlich geänderte Funktionalität validiert werden.
Natürlich werden die verwendeten
Sourcen in der Quelltextverwaltung mit
einem Label versehen. Dieses Label wird
auch im Log aufgeführt. Somit ist jeder
Builds nachvollziehbar. Dies ist hilfreich
falls Probleme mit einem bereits ausgelieferten
Software-Stand nachvollzogen
werden müssen. Anhand des Labels und
des Team Build kann genau ermittelt werden,
welche Quelltextdateien in welcher
Version zum Erzeugen eines Programms
verwendet wurden. Dies erleichtert zum
einen das Nachverfolgen von Fehlern, zum
anderen kann auch im Rahmen einer Auditierung
aufgezeigt werden, welche Funktionalität
in den einzelnen Versionen eines
Programms geliefert wurde. Die Interna
eines Build Types sind dann interessant,
wenn Anpassungen oder Erweiterungen
am Ablauf eines Builds vorzunehmen sind.
Zuerst ein Blick auf die Team Build Datei
selbst. Diese befindet sich unter \
Targets bei MSBuild
Die Sprache MSBuild ist eng verwandt mit Ant/Nant. Hier können deklarativ sog. Targets angegeben werden. Diese Targets sind Einsprungpunkte für den Build-Prozess und bestehen aus einer Reihenfolge von Tasks. Durch die Angabe von Abhängigkeiten der Targets untereinander, können ganze Ketten von Befehlsfolgen aufgebaut werden, die die sequentielle Abarbeitung von Targets im Build-Prozess erlauben, aber auch die Wiederverwendung von Teilen dieser Targets erlauben. Team Build definiert ganz bestimmte Punkte in der Reihenfolge der Targets, die für eigene Erweiterungen verwendet werden können: Z.B. bietet sich das Target AfterGet an, um ein bestimmtes Tool laufen zu lassen, nachdem der Build-Prozess alle notwendigen Dateien aus der Quelltextverwaltung geholt hat. Das Target kann in der Datei TFSBuild.proj definiert werden und wird automatisch von Team Build zum angegeben Zeitpunkt aufgerufen. TeamBuild.targets wird in jeder TFSBuild.proj referenziert und bietet eben diese zusätzlichen Tasks und Targets für Team Build an.
Das Import-Konzept von MSBuild bringt eine gute Möglichkeit, Teile einer Build-Datei, wie selbst geschriebene Targets, aus einer Datei auszulagern und in einem anderen Team Build wiederzuverwenden. Somit kann man auch komplexe Team Builds gut im Griff behalten. Wem diese Erweiterungsmöglichkeiten nicht ausreichen, dem steht die Möglichkeit offen, eigene Tasks zu entwickeln. Diese können durch Ableitung von einer .NET-Klasse mit wenigen Zeilen Code entstehen. Mögliche Beispiele hierfür sind eine eigene Systematik zur Erzeugung einer Build-Nummer, oder auch ein Task der Assembly-Versionsinformationen in die AssemblyInfo.cs einfügt. Beispiele für Tasks finden sich inzwischen reichhaltig im Internet und anhand bestehender Beispiele ist es sicherlich möglich, für die eigene Problemstellung Lösungen zu finden. Microsoft selbst liefert hier auch immer wieder Erweiterungen in Form der Power Tools. So zum Beispiel einen Build Task zum vereinfachten Ausführen von Unit Tests ohne den Umweg der Testlisten. Der Task zum Ändern der Versionsinformation einer Assembly findet sich zum Beispiel auch an vielen Stellen im Internet. Die Community bietet hier rege Unterstützung und ergänzt die Standardfunktionalitäten auch um zusätzliche, nützliche Features.
Wichtig ist in diesem Zusammenhang auch die erwähnte Continuous Integration. Hierbei wird bei jedem Check-In in die Quelltextverwaltung ein Kompiliervorgang auf dem Server angestoßen, der die Verträglichkeit der Änderungen mit den bestehenden Sourcen prüft. Das gefürchtete „Brechen“ eines Builds, oder schlimmer die aufwändige Integration von Sourcen verschiedener Entwickler, wird durch die Überprüfung in der kleinsten Einheit, dem Check-In vermieden. Als Technik inzwischen weit etabliert, steht Continuous Integration (noch) nicht als Standardlösung von Microsoft zur Verfügung. Allerdings gibt es ein Paar frei erhältliche Lösungen im Internet und Continuous Integration soll auch im nächsten Release des Team Foundation Server angeboten werden.
Insgesamt bietet Team Build mit seinem Wizard eine gute Möglichkeit schnell und unkompliziert einen Daily Build aufzusetzen. Allerdings wird man als Configuration Manager schnell mit der ganzen Komplexität von MSBuild konfrontiert. Zudem ist das Entwickeln und Testen eines Team Builds eine u.U. zeitaufwändige Arbeit. Allerdings lohnen die Automatisierung und die erzeugten Statistiken auf alle Fälle die investierten Mühen.
Thomas Janssen und Markus Schiller sind als Berater für Software Configuration Management bei der TRIA IT-consulting GmbH tätig. Sie unterstützen mehrere deutsche DAX-Unternehmen beim Einsatz von Visual Studio Team System.
