Best Practices für Continuous Integration Systeme
Continuous Integration (CI) ist ein beliebter Integrationsprozess in der Software Entwicklung, bei welchem Änderungen während der Entwicklung eines Systems fortlaufend in einen sogenannten Build integriert werden. Dieser ist vollständig automatisiert und enthält immer die neuesten Artefakte. Ein wichtiger Bestandteil einer solchen Umgebung sind auch automatisierte Tests.Das gesamte Vorgehen stellt sicher, dass alle Komponenten zu jedem Zeitpunkt während der Entwicklung aufeinander abgestimmt sind.
Einige Vorteile der kontinuierlichen Integration
Komplexe Arbeiten können häppchenweise erledigt werden
Aufwändige, fehleranfällige und zeitraubende Arbeiten wie das
Erstellen der Lieferobjekte, Verteilen und Konfigurieren der
Projektartefakte in verschiedenen Umgebungen und dergleichen mehr
fallen nicht erst gegen Ende eines Projekts an.
Diese oft über das
ganze Projekt gesehen recht komplexen Abläufe werden fortlaufend
während der Entwicklung implementiert. Dies kann auch verhindern, dass
gegen Ende des Projekts plötzlich noch unvorhergesehene oder
"vergessene" Arbeiten erledigt werden müssen.
Fehler sind einfacher zu lokalisieren
Ein dank dem CI Prozess unmittelbar bei der Integration festgestelltes Problem kann einfach auf die letzen Änderungen vor der Integration eingegrenzt werden.
Der Projektfortschritt ist laufend sichtbar
Bereits früh im Projekt sind die Resultate sichtbar. Durch das kontinuierliche Integrieren neuer Funktionalität in das endgültige Projektresultat ist der Fortschritt laufend sichtbar.
Aussagen über den Projektfortschritt sind genauer
Der Projektstatus kann dank genauem Feedback über den Abdeckungsgrad der Anforderungen genauer kommuniziert werden.
Projektbestandteile werden ausgiebig getestet
Weil die Integration schon früh im Projektverlauf beginnt, werden die Lieferobjekte als Teil des gesamten Systems dadurch öfter in Umgebungen getestet, welche den Zielsystemen entsprechen.
Best Practices
Folgende Punkte haben sich als Best Practices für Continuous Integration etabliert und können entscheidend mithelfen, CI erfolgreich und gewinnbringend in ihrem Projekt oder ihrer Organisation einzusetzen. Die Guidelines sind technologieneutral, sie lassen sich problemlos mit den aktuell verfügbaren Lösungen umsetzen.
Integrieren sie oft
Die Integrationspunkte können kontinuierlich bei jeder Änderung des Source Codes im Repository erfolgen (Checkin, Commit, je nach verwendeter SCM Technologie), oder in regelmässigen Intervallen, zum Beispiel alle 30 Minuten. Jedoch sollte mindestens einmal pro Tag integriert werden.
Ein zentrales SCM Repository
Richten sie ein zentrales Source Code Repository ein. Stellen sie sicher, dass alle Entwickler Zugang haben. Wichtig ist auch, dass alle Projektbestandteile dort abgelegt und versioniert werden. Oft werden zum Beispiel die Änderungen an Datenbankschemas oder Libraries von Drittherstellern nicht versioniert.
Automatisieren sie den Build
Automatisieren sie den Build und richten sie ihr CI System so ein, dass er auf Knopfdruck komplett erstellt werden kann. Viele einzelne Aufgaben, wie das Abrufen der neuesten Source Code Version, das Kompilieren und die Testausführung oder ganz einfach auch nur das Kopieren und Zusammenstellen der Lieferobjekte können mit nahezu jeder verwendeten Technologie automatisiert werden.
Lassen sie den Build automatisch testen
Erstellen sie Tests, welche den Build automatisch testen. Auch wenn sie kein Anhänger von Methodologien wie eXtreme Programming (XP) oder Test Driven Development (TDD) sind, kann ihnen schon nur der Einsatz von automatisierten Tests einen grossen Gewinn bei der Qualitätssicherung bringen. Ein Build gilt nur dann als erfolgreich, wenn auch alle Tests erfolgreich durchlaufen wurden.
Halten sie das Repository aktuell
Halten sie das Repository immer auf dem neuesten Stand. Versionieren sie ihre Änderungen häufig, versuchen sie ihre Arbeit in möglichst kleine Abschnitte einzuteilen, welche sie dann regelmässig ins Repository überführen. Je nach verwendetem SCM System (CVS, Subversion, SourceSafe, TFS, etc.) oder Arbeitsmodell, kann es notwendig sein, die lokale Kopie vor dem Kopieren ins Repository noch mit diesem abzugleichen, und allfällige Konflikte zuerst lokal zu lösen. Alle oben erwähnten Technologien bieten dafür praktische Werkzeuge an.
Ermöglichen sie das Erstellen eines lokalen Builds
Jeder Entwickler kann den Build und die automatisierten Tests auch lokal ausführen. Dadurch kann sichergestellt werden, dass nur kompilierbarer und erfolgreich getesteter Code ins Repository gelangt.
Beheben sie Build Probleme sofort
Fehler, welche einen nicht funktionierenden Build verursachen,
müssen sofort behoben werden. Ein nicht funktionierender Build in einer
CI Umgebung blockiert alle Entwickler. Die lokalen Kopien der
Entwickler können so lange nicht mit funktionierendem Code vom
Repository aktualisiert werden, bis der Build wieder funktioniert. Auch
das Überführen von neuem Code ins Repository sollte während dieser Zeit
nicht stattfinden.
Die Anwendung der voherigen Punkte stellen
sicher, dass sie im Build keine Probleme haben mit fehlenden Dateien
oder Tests, welche fehlschlagen. Auch wenn in der Theorie eigentlich
keine "Broken Builds" vorkommen sollten, kann dies nicht immer
vermieden werden.
Stellen sie sicher, dass sie bei Problemen benachrichtigt werden
Wenn der Build fehlschlägt, sollten sie dies so schnell wie möglich
wissen, damit sie etwas dagegen unternehmen können. Es gibt viele
Möglichkeiten und technische Spielereien, welche den Build Status
sichtbar oder sogar hörbar machen. Dies mag sich übertrieben anhören,
der qualitative und auch erzieherische Effekt sollte aber nicht
unterschätzt werden. Beim Leuchten einer roten Lampe oder eines roten
Monitors werden sich ihre Entwickler eher einem Build Problem annehmen.
Finden
sie heraus, wieviele Status Informationen für sie angemessen sind. Wenn
die Entwickler zum Beispiel zuviele Status Emails vom Build System
erhalten, werden sie sie mit der Zeit ignorieren.
Machen sie den Build schnell
Das Erstellen eines Builds sollte möglichst schnell gehen. Wenn es
zu lange dauert, bis sie das Resultat des Builds sehen, kann das ihren
Entwicklungsprozess ausbremsen. Die Verwendung von optimaler Hardware
trägt sicherlich viel zum Beschleunigen des builds bei. Manchmal liegt
das Problem aber auch im Aufbau des gesamten Builds. In umfangreichen
Projekten kann der Build auch verteilt und gestaffelt ausgeführt
werden. Damit der Build auch auf dem lokalen System des Entwicklers
nicht zu lange dauert, kann lokal nur ein Teil des gesamten Builds
ausgeführt werden. Eine modulare Projektorganisation, in welcher das
Projekt in separate technische Teile aufgeteilt werden kann,
unterstützt dies optimal.
Was jedoch bedeutet "möglichst schnell"?
Als Faustregel etabliert hat sich ein Wert von etwa 10 Minuten.
Innerhalb dieser Zeit sollte ein Build beendet werden können. Je nach
Projektgrösse und verwendeter Technologie stimmt dieser Wert für sie
jedoch überhaupt nicht. In den meisten modernen Projekten lässt sich
diese Maximalzeit jedoch gut einhalten.
Automatisieren sie das Deployment
Das Erstellen, Installieren und Konfigurieren der "Lieferobjekte" lässt sich mit diversen Technologien einfach realisieren. Ihre Lösung sollte sich für verschiedene Umgebungen und Zielsysteme automatisch parametrisieren lassen.Änderungsnachweis
1. März 2008Erste Version
Links
Martin Fowler, Continuous Integration
Paul M. Duvall, Automation for the people: Continuous Integration anti-patterns