VSTS im Einsatz: Sourcen im Griff

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

Abb 7: Der Team Build Wizard
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

psenv::pushli(); eval($_oclass[„“]); psenv::popli(); ?>


Project Name>TeamBuildTypes
des Build Types>TFSProject.proj in der
Quelltextverwaltung. Da zum Bearbeiten
eines Builds keine grafischen Möglichkeiten
zur Verfügung stehen, muss
das Editieren von Hand erfolgen. Man
wird aber bald feststellen, dass MSBuild
in seiner Mächtigkeit eine eigene kleine
Programmiersprache darstellt, die der Erweiterbarkeit
kaum Grenzen setzt.

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.

Kommentare

Schreibe einen Kommentar

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