Buch-Rezension zu "Continuous Integration"

"Continuous Integration" von Paul Duval erschien 2007 bei Addison-Wesley. Bei Continuous Integration, oder kurz CI, denkt man als erstes an einen automatischen Build. Paul Duval zeigt was sonst noch alles dazu gehört und gerne vergessen geht.

Duval sah am Anfang seiner Kariere eine Werbung, bei der es auf der Tastatur einen Knopf mit der Beschriftung "Integrate" gab. Darunter stand "wenn es doch nur so einfach wäre". Ein komplexes Produkt einfach durch das drücken einer Taste zu bauen und in die Produktion einzuführen. Nicht mehr tagelang in der Integrationshölle verbringen sondern nur ein Tastendruck. Tönt unmöglich? Ist es aber nicht.

Notwendige Grundlagen

Um Continuous Integration zu benutzten, braucht man unbedingt eine Versionsverwaltung für den Source Code. Nur wenn der gesamte Code an einer zentralen Stelle abgelegt ist, kann man auch alles zusammen bauen. Ist diese Voraussetzung erfüllt, kommt der CI-Server. Dieser wird aus der Versionsverwaltung den Code holen und das Projekt bauen. Ein Build Script kann dies stark vereinfachen. Kapitel 1 und 2 gehen auf diese Grundlagen ein und zeigen, wie CI in die Entwicklung passt.

Risiken minimieren

Wozu soll man CI nutzen? Wer schon einmal ein grösseres System integriert hat, hat sich mit Problemen herumschlagen müssen. Kommen die einzelnen Module zum ersten Mal zusammen, stösst man meistens auf Probleme. Je mehr Module zusammen kommen, desto grösser die Probleme. Dies kann man durch kleinere und häufigere Integrationen abfedern. Die kleinstmögliche Änderung am System ist ein commit in die Versionsverwaltung. Daraus folgt, dass der kleinstmögliche Integrationsschritt ebenfalls der commit ist. Bei jedem commit automatisch einen Build samt Integration aller Module ist so eine logische Schlussfolgerung. Und da es voll automatisiert abläuft, geht dies ohne einen Mehraufwand. Der CI Server wird einmal konfiguriert und läuft dann von alleine.

Die Integration der einzelnen Teile ist aber nicht die einzige Möglichkeit für Fehler. Auch die Tests müssen laufen - und zwar immer. Neben dem Bauen der Software soll daher auch die Testsuiten bei jedem commit ausgeführt werden. So bemerkt man sofort, wenn etwas nicht mehr funktioniert. Man kann dann den Fehler reparieren solange man noch weiss, was man geändert hat. Macht man dies erst Wochen später, wird das sehr aufwendig.

Diese Tests sind nicht nur auf Unit-Tests limitiert. Hat man auch die Funktionstests automatisiert, können auch diese ausgeführt werden. Nutzt man Funktionstests zum Messen des Projektfortschritts, weiss man so immer wo man steht. Wenn 15 von 30 Tests laufen ist dies ein deutlich klarere Aussage als "wir sind zu 95% fertig". Man kann den Fortschritt laufend messen und steuert nicht auf die grosse Überraschung am Ende der Iteration zu.

Qualität überwachen

Neben der automatisierten Ausführung von Tests kann man auch die Qualität der Software überwachen. Code Metriken können durch entsprechende Tools erfasst werden. Je komplexer eine Methode, desto Fehleranfällig wird diese. Wenn man die Komplexität beobachtet, kann man frühzeitig und gezielt darauf eingehen. Gleiches gilt für duplizierten Code. Findet man den bevor man in nur einer Kopie einen Fehler repariert, spart man sich unnötige Arbeit.

Gibt es Coding-Standards, kann man diese ebenfalls überwachen lassen. Auch hier gilt wieder je eher man Abweichungen findet und diese behebt, desto weniger Aufwand ist nötig. Zu diesen und noch weiteren Punkten liefert der zweite Teil des Buches zahlreiche Tipps.

Feedback und Reaktion

Die ganze Automatisierung nutzt allerdings nur etwas, wenn man die Ergebnisse des CI-Servers überwacht. Schlägt ein Build fehl, muss er sofort repariert werden. Schlagen Tests fehl, muss man reagieren. Die richtigen Leute müssen zur richtigen Zeit erreicht werden. Duval beschreibt etliche Möglichkeiten, wie man das Feedback vom CI-Server zu den Entwicklern bekommt. E-Mail, SMS, Jabber oder auch Lavalampen können je nach Situation zum Einsatz kommen. Und dann muss man reagieren. Nur zu wissen das man ein Problem hat behebt dieses noch lange nicht. Ohne das sich jemand darum kümmert wird das am Tag des Release noch bestehen.

Automatische Verteilung der Software

Zu guter Letzt soll auch die Verteilung der Software automatisch ablaufen. Ein Knopf drücken und es wird kompiliert, getestet, geprüft und verteilt. Hat man den Punkt erreicht, ist die Integrationshölle definitiv überwunden. So eröffnen sich neue Möglichkeiten. Wenn der Aufwand für ein einzelnes Release minimal ist, kann man häufiger releasen. Kann man dem Kunden jede Woche eine funktionierende Demo präsentieren, können falsch verstandene Anforderungen schnell entdeckt werden. Statt für Monate in eine falsche Richtung zu entwickeln verliert man nur Tage. Auch hier wieder eine Reduktion von Aufwand und Kosten durch die Automatisierung.

Fazit

Paul Duval gelingt es die Vorteile von Continuous Integration klar darzulegen. Das Thema CI stoppt nicht bei automatischen Builds, sondern geht deutlich weiter. Schön ist ebenfalls, das man CI nach und nach ausbauen kann. Dabei hilft einem das Buch als Wegweiser. Will man von CI maximal profitieren, sollte man am Ende aber alles automatisieren. Dies benötigt Zeit und je nach dem etliche Änderungen am Ablauf. Der Aufwand ist aber minimal im Vergleich zu den Vorteilen, den man durch die Automatisierung gewinnt.

Die rund 300 Seiten sind gut um einem einen Überblick zu liefern und bei entsprechendem Vorwissen eine CI-Umgebung aufzubauen. Wie man einen speziellen CI-Server konfigurieren muss oder was Ant oder Maven alles bieten wird dabei nicht erklärt. Beginnt man ganz von vorne, wird man zusätzliche Bücher benötigen, die auf die einzelnen Teile genauer eingehen.

Da im Bereich von CI sehr viel in Bewegung ist, sollte man sich auch die Webseite zum Buch anschauen. Auf https://www.integratebutton.com/ gibt es Videos, weiterführende Links und die vorgestellten Skripte als Download.

Zum Buch

"Continuous Integration: Improving Software Quality and Reducing Risk" von Paul M. Duval, Steve Matyas und Andrew Glover, 2007 Addison-Wesley, ISBN 978-0-321-33638-5, 336 Seiten