Continuous Integration

Qualität und zwar ständig!

17.02.2015 08:28 von Alexander Vukovic

Was verbirgt sich hinter Continuous Integration (kurz CI)? Und wohin geht die Reise? 1994 wurde das Konzept der CI von Grady Booch erstmals erwähnt. Später fand es im Extreme Programming Eingang und war damit Grundlage für die unterschiedlichsten agilen Vorgehensweisen, die sich von Extreme Programming inspirieren ließen. Heute ist CI state of the art und nicht nur fixer Bestandteil in agilen, sondern auch in traditionellen Projekten, die immer mehr agile Techniken umsetzen, um schneller zu werden.

Was verbirgt sich CI? Und wohin geht die Reise? Um diese Fragen zu beantworten, ist es wichtig zuerst die Motivation dahinter zu beleuchten. Warum braucht man überhaupt CI? Die Antwort lautet „Immediate Feedback“. Dieses Konzept versucht, dem Team und dabei insbesondere dem Entwickler, schnellstmöglich („Immediate“) Feedback über die Qualität seiner Software nach einer Änderung zu geben. Dazu ist es notwendig, die Änderungen jedes einzelnen auch so rasch wie möglich mit dem Gesamtstand zu integrieren und integriert zu testen. Betrachtet man die ideale Testautomationspyramide, so sollten die Unit Tests die breiteste Abdeckung mit den kleinstmöglichen Einheiten (Methoden) bilden. Die Unit Tests sollten in Sekunden ablaufen, sodass sie rasch Rückmeldung geben können (API und Component Tests laufen Minuten, Automated GUI Tests aufgrund ihrer Komplexität meist Stunden).

Die Unit Tests laufen nach jeder Änderung, nach jedem Compile bereits in der lokalen Entwicklungsumgebung des Entwicklers. Sind die lokalen Tests erfolgreich abgeschlossen, so kann es der Entwickler riskieren, seine Änderungen bestmöglich in den Gesamtstand zu integrieren. Das erfolgt über ein VCS (Version Control System), wie z.B. Subversion. Das heißt, der Entwickler „committed“ seine Änderungen in die zentrale Source Code-Verwaltung. Nun kann in der Zwischenzeit auch ein anderer Entwickler Änderungen vorgenommen haben und diese bereits im zentralen Repository verfügbar gemacht haben. Das CI-System stellt sicher, dass der Entwickler so rasch wie möglich Feedback bekommt, ob seine Änderungen auch integriert mit dem Letztstand funktionieren, oder ob er etwas kaputt gemacht hat.

Manche Teams machen dies seriöser mittels einer Ampel oder einem öffentlichen Bildschirm im Teamraum. Dabei wird der Build-Erfolg visualisiert. Das CI-System wird meist auf einem eigenen Server installiert (genannt CI oder Buildserver) und prüft entweder zyklisch (z.B. stündlich oder einmal pro Nacht, „Nightly Build“) ob es Änderungen am System gab. Viele Teams konfigurieren das CI-System so, dass es bei jeder Änderung im Repository los läuft.

Was sind nun die Kern-Aufgaben des CI-Systems? Es automatisiert alle Qualitätsmaßnahmen und Schritte, um zu einem testbaren Build der Software zu gelangen. Diese Schritte waren früher sehr langsam und fehleranfällig. So erinnere ich mich an ein großes Smalltalk-Projekt in den 90ern, das ich begleiten durfte, bei dem es noch ein eigenes Build-Team gab, das innerhalb von einer Woche eine testbare Software „zusammenbaute“.

Das ist ebenfalls ein agiles Kernkonzept, das CI abbildet: Dinge, die man nur zeitaufwändig und fehleranfällig machen kann, mache so oft wie möglich, um sie zu optimieren und zu automatisieren! Das CI-System übernimmt nun diese wiederholenden Aufgaben:

Checkout des letzten Gesamtstandes aus dem Versionsrepository
Compiling und Linking des Source Codes = erste Qualitätsüberprüfung des Codes
Durchführung der Unit Tests mit dem neuen Build = zweite Qualitätsprüfung: Laufen die Tests der kleinen Einheiten noch?
Code Style Guide sicherstellen = dritte Qualitätsprüfung: Entspricht der Code unserem Styleguide um wartbar zu sein?
Automatischer Code Review = vierte Qualitätsprüfung auf typische Fehler, die durch statische Codeanalyse automatisiert geprüft und erkannt werden können
Code Coverage Analyse = fünfte Qualitätsprüfung, die den Abdeckungsgrad des Source Codes mit Unit Tests misst

Bis hierher sprechen wir von einer Durchführung in Sekunden. Wenn das Team das CI-System so konfiguriert hat, dass es bei jeder Änderung neu baut, bekommt der Entwickler, innerhalb von Sekunden die Rückmeldung, ob diese Version läuft oder nicht. Die weiteren Schritte sind:

Automatische Durchführung der API- und Component Tests = sechste Qualitätsprüfung, die größere Einheiten miteinander integriert und einige Minuten läuft
Automatische Durchführung der GUI-Tests = siebente Qualitätsprüfung, diese wird aber meist aufgrund der Dauer von mehreren Stunden in einen eigenen Build ausgelagert, der erst bei erfolgreichem Basisbuild angestoßen wird.
Packaging, z.B. WAR-File, EXE
Deployment in eine Testumgebung
Erstellen eines Buildreports und der Buildstatistiken
Verständigung aller Teammitglieder

All diese Schritte passieren laufend und automatisch, das Team kann sich auf seine eigentliche Aufgabe - die Softwareentwicklung - konzentrieren. Nach jeder Änderung steht eine deploybare und manuell testbare Version zur Verfügung. Ein CI-System ist ein sehr mächtiges Tool und kann für viele andere Tasks herangezogen werden. So haben wir beispielsweise CI für Batch Testing oder für Releaseautomation in Kundenprojekten implementiert. Die Möglichkeiten sind grenzenlos und die Kosten gering. So sind die gängigsten und leistungsfähigsten CI-Systeme heute als Open Source verfügbar und ohne Lizenzkosten einsetzbar. Natürlich ist es wichtig, dass das CI-System nicht zum Selbstzweck wird und das Team sich nicht zu lange mit der Toolauswahl und Konfiguration aufhalten muss.

Schon gewusst?

Wir bieten spezielle Dienstleistungen für CI an. Diese reichen von der Beratung und Schulung Ihres Teams bis hin zu Design und Implementierung einer Best-Fit-CI für Ihren individuellen Kontext.

Wir freuen uns darauf, Sie bei der Implementierung Ihres CI-Systems zu unterstützen, für Ihre Qualität - und zwar ständig!