Who broke the build – Teil I

VS_BuildManagementAutomatische Build-Mechanismen, wie sie beispielsweise der TFS 2013 bietet, sind in modernen Entwicklungsprojekten kaum noch wegzudenken. Automatische Builds unterstützen die tägliche Arbeit einer Entwicklungsmannschaft, helfen beim Schreiben von qualitativ hochwertigen Code und bei der Integration unterschiedlicher Software-Module. „Nightly Builds“ können z.B. jede Nacht die Qualität des aktuellen Source Code Standes prüfen und so den Entwicklern ein Feedback über Ihr Tagwerk zur Verfügung stellen. Diese Feedback-Option ist gut und kann die Source Code Qualität steigern – aber nur, wenn diesem Feedback auch Beachtung geschenkt wird.

Wenn mehrere hundert Entwickler, in verschiedenen Abteilungen, an diversen Modulen arbeiten und versuchen erst zum Ablauf eines Entwicklungszeitraums, alle Module zu einer lauffähigen Version zusammenzufügen, kann es durchaus ein böses Erwachen geben. Module, die unabhängig voneinander entwickelt worden sind und dazu gedacht waren eng zusammenzuarbeiten, können nicht integriert werden. Vermeintlich einfache Schnittstellen können nicht mehr verwendet werden, weil der Ersteller kurz vor Schluss noch eine Änderung eingecheckt hat. Und der Tag des Release rückt immer näher.

Dank Continuous Integration und dem Einsatz von geeigneten Werkzeugen (z.B. TFS 2013), lässt sich die Komplexität bei der Integration von Source Code und der Erstellung von Software besser beherrschen. Automatische Builds spielen dabei eine entscheidende Rolle. Sie geben Feedback zur aktuellen Softwarequalität und dem Integrationsstand aller Module.

Ein Build für alle Fälle

Continuous Integration Builds

Ein Build kann „persönlich“ oder „unpersönlich“ sein. Ein persönlicher Build wird normalerweise von einem Entwickler ausgelöst und liefert Informationen zurück, die für die auslösende Person von Interesse sind. Ein Continuous Integration Build, auch CI-Build genannt, wir in der Regel immer dann ausgelöst, wenn ein Entwickler Source Code in die Versionskontrolle aufgenommen hat. Der CI-Build prüft genau den Source Code Stand, der unmittelbar nach dem Eincheckvorgang auf dem Versionskontroll-Server liegt und gibt je nach Konfiguration Feedback über Kompilierbarkeit, Testbarkeit oder Code-Qualität.

Ein Nachteil an diesem Build-Typ ist, dass eventuell negatives Feedback vom Entwickler ignoriert werden kann und damit Source Code in die Versionskontrolle gelangt und dem Gesamt-System schadet. Entweder weil sich der Versionsstand nicht mehr kompilieren lässt, Testfälle fehlschlagen oder allgemein die Code-Qualität nicht mehr gewährleistet ist.

Um diesem Nachteil zu entgehen, gibt es im Team Foundation Server einen sogenannten Gated Check-In. Dieser Build-Typ prüft den einzucheckenden Source Code vor der Aufnahme in die Versionskontrolle. Damit ist er sogar noch ein bisschen persönlicher, da potentiell nur der Source Code des auslösenden Entwicklers auf Validität geprüft wird.

Build Mechanism

Fällt die Rückmeldung des Gated Check-In negativ aus, muss der Entwickler reagieren und Anpassungen an seinem Code vornehmen, sonst würde der Source Code nicht in die Versionskontrolle aufgenommen werden und der Entwickler könnte somit nicht seinen Teil zum Gesamtsystem leisten.

Geplante (scheduled) Builds

Die geplanten Builds, oft auch Nightly-Builds genannt, sind eher unpersönliche Builds. Sie prüfen alle Check-Ins eines Tages und somit Code von verschiedenen Entwicklern oder Abteilungen. Dieser Build-Typ wird häufig nachts durchgeführt, weil erstens alle Check-Ins auf Integrität geprüft werden sollen und zweitens oft auch ein erweitertes Set von automatisierten Tests zur Ausführung kommt. Dadurch ergeben sich meist auch längere Laufzeiten und höhere Last auf dem Build Server, wodurch sich die Ausführung in der Nacht anbietet. Daher auch der Name „Nightly Build“.

Da dieser Build eher global und unpersönlich ist, wird sein Feedback oftmals ignoriert. Manchmal scheinen die Entwickler gar zu denken „wenn ich mich nicht kümmere, dann wird es schon jemand anderes tun“. Aber das ist schade! Denn so leidet der Grundgedanke des globalen Feedbacks und die Qualität des Source Code Standes wird gefährdet. Und langfristig eventuell auch die Auslieferung der Software.

Eine Frage der Motivation

Geprägt durch diese Erfahrung, könnte man sich durchaus die Frage stellen, ob es irgendwie möglich ist, Entwickler zu mehr Verantwortung zu motivieren. Oder vielmehr den Sinn dafür zu schärfen, sich für etwas verantwortlich zu fühlen, das nur als Gemeinschaftswerk Erfolg haben kann. Neben zahlreichen Appellen an das Team-Gefühl und der Wichtigkeit der Builds, scheint mir auch die Optimierung der vorhanden Informationen wichtig zu sein. Grundsätzlich stellt der Team Foundation Server zahlreiche Möglichkeiten zur Informationsbeschaffung und Build-Überwachung bereit (z.B. TFS Web Access, Team Explorer im Visual Studio, Build Notification Client, etc), aber all das scheint manchmal nicht auszureichen. Zugegeben, die Motivation eines Mitarbeiters kann nicht durch ein paar nette Werkzeuge und Automatismen gesteigert werden. Dazu sind ganz andere Faktoren wichtig, die ich aber an dieser Stelle nicht diskutieren möchte. Aber manchmal hilft es auch, die Motivation für eine Sache zu steigern, wenn es um das persönliche Ehrgefühl geht. In der dotnetpro Ausgabe 02/2014 schreibt Andy Grothe über den Abruf von Build-Status Information über die TFS-API. Inspiriert von diesem Artikel entstand ein ähnliches Tool, welches aus einem TFS 2013 die Nightly-Builds ausliest, die Informationen in ein html-Format schreibt und dann die Information per Mail über die Microsoft Exchange Services an alle Entwickler verteilt.

MailResult_short_2

Im zweiten Teil von „Who broke the Build“ werde ich erklären, wie so ein Mechanismus aussehen könnte. Und um das Beispiel möglichst einfach zu halten, ist der Mechanismus in eine Konsolenapplikation implementiert, die auf dem TFS App Tier als Scheduled Task ausgeführt wird.

[1] dotnetpro 02/14 Andy Grothe – Sie haben Post