Erfahrungsbericht: Einführung eines Gated Check-In Builds

Zur Steigerung der Qualität in Softwareprojekten kann man verschiedene Maßnahmen treffen. Eine Methode ist der Einsatz eines Gated Check-In Builds,  welcher die Erstellung eines integrierten Code-Stands sicherstellt. Doch welche Veränderungen bringt das für ein Entwicklungsteam mit sich und wie könnte sich deren Arbeitsablauf verändern? Es folgt ein Erfahrungsbericht über die Einführung von Gated Check-In Builds,  inklusive Sorgenfalten und Erfolgsmeldungen.

Der zentrale Gedanke von Continuous Integration ist die häufige oder kontinuierliche Integration von geänderten oder neuen Code-Artefakten in den bestehenden Source Code. Im Optimalfall führt das zu mehreren Integrationen pro Tag. Durch diese kontinuierliche Einarbeitung von neuen Code-Artefakten sollen Integrationsfehler und Inkompatibilitäten schneller aufgedeckt und behoben werden, was langfristig zu einer höheren Code-Qualität führt. Ein Hilfsmittel auf diesem Weg sind Continuous Integration Builds. Diese automatischen Builds versuchen den eingecheckten Code zu compilieren und geben dem Entwickler darüber Auskunft, ob ihr Stück Code dem Gesamt-Code-Stand „schadet“ oder nicht.

GatedCheckIn

Abbildung: Einstellung für Continuous Integration Build des Team Foundation Server 2013

Der Nachteil dieser Methode ist, dass Source Code bereits in den Integrationsstand eingefügt wird, bevor er auf seine Kompilierbarkeit überprüft worden ist. Die Folgen kennen wir alle – der Nächste der eincheckt, bekommt einen Fehler und muss sich auf die Suche nach der Ursache machen. Oder keiner kümmert sich darum und der nächtliche Build-Lauf schlägt fehl.

Ein Entwicklungsteam lernt aber im Laufe der Zeit auch mit solchen Hürden umzugehen. So finden sich immer einige Feuerwehrleute und Brandbekämpfer, die für die Allgemeinheit das Feuer löschen. Doch effektiv ist das nicht und raubt den freiwilligen Helfern die Zeit zum Entwickeln. Viel besser wäre es, wenn der Fehler bereits beim Verursacher sichtbar wird, denn dieser kann wesentlich zielgerichteter nach der Ursache suchen.

Eine Möglichkeit um Verunreinigungen im integrierten Source-Stand zu vermeiden, ist der Einsatz eines „Türstehers“ – eines sogenannten Gated Check-In. Dieser „Türsteher“ sorgt dann dafür, dass nur integrierbarer Code in den Source-Stand gelangt. Der Gated Check-In kompiliert erst den Source Code (prüft sozusagen sein „Outfit“ und den „Perso“), bevor er dem Zutritt zustimmt und den Check-In-Vorgang anstößt. Die genaue Funktionsweise eines Gated Check-In Builds ist z.B. auf den Seiten des MSDN beschrieben.

GatedCheckIn_I

Abbildung: Einstellung für Gated Check-In Build des Team Foundation Server 2013

Mit dieser Maßnahme soll also die Zahl der Build-Abbrüche minimiert und der Gedanke von Continuous Deployment wieder belebt werden. Doch wie reagiert ein Team, dass kaum Regeln gewohnt ist, auf so einen Eingriff? Was passiert mit der Lebensweise „Check-In and forget“? Wie reagiert ein System, bestehend aus einem Dutzent Teilprojekten und mit mehr als 100 Entwicklern?

Die Befürchtungen von Boykott und Sabotage waren unbegründet. Bis auf einige wenige Meckerer (zugegeben: wir sind hier in Franken. Und wenn ein Franke nichts zu meckern hat, dann stimmt ohnehin etwas nicht) gab es nur positive Stimmen. Viele sind froh über ein wenig Regelwerk, dass am Ende auch noch verhindern kann, das man der Buh-Mann ist, der den Build geschmissen hat.

Sicherlich hat eine ausführliche Informationsveranstaltung vor der Einführung einen Teil dazu beigetragen, dass Ängste und Unsicherheiten abgebaut werden konnten. Die Fragen, die zur Einführung von den Entwicklern gestellt wurden, waren überschaubar. „Was ist mit Breaking Changes?“, „Kann ich etwas am System kaputt machen, wenn der Build fehl schlägt?“ und „Wie lange dauert der Build?“.

Die darauffolgenden Tage nach der Einführung waren unspektakulärer als erwartet. Es traten zwar kleinere Fehler im Build-Prozess auf, die hatten aber nichts mit dem Gated Check-In zu tun. Auch wenn die Fehler erst mal von dem einen oder anderen Entwickler auf „das NEUE“ zurückgeführt wurden…

Fazit

In der durchgeführten Retrospektive waren die Äusserungen zum eingeführten Gated Check-In sehr positiv. Es gibt keine größeren Schwierigkeiten und die gewonnene Sicherheit und Stabilität wird unter den Entwicklern sehr begrüßt. Manch einer hätte sich einen Gated Check-In sogar schon früher gewünscht.

Hinweis: Wer mehr zu Continuous Integration lesen möchte, findet bei Martin Fowler noch mehr Informationen dazu.