Kontinuierliche Integration

Kontinuierliche Integration (auch: fortlaufende oder permanente Integration, en. Continuous Integration) ist ein Begriff aus der Software-Entwicklung, der den Prozess des regelmäßigen, vollständigen Neubildens und Testens einer Anwendung beschreibt. Obwohl dieses Konzept älter ist, wird es häufig mit Extreme Programming in Verbindung gebracht.

Die Idee der fortlaufenden Integration ist einfach: ^[1]

1. Jeder Entwickler soll frühzeitig und oft Änderungen in die Versionsverwaltung einchecken d. h. er sollte versuchen, eine große Änderung inkrementell durch funktionsfähige kleine Änderungen einzubringen. Normalerweise sollte jeder Entwickler mindestens täglich seine Änderungen einchecken.
2. Sobald ein Entwickler Änderungen in die Versionsverwaltung eincheckt, wird das Gesamtsystem neu gebaut und automatisch getestet. Es wird versucht, den Entwickler so schnell wie möglich auf Integrationsprobleme seiner Änderung hinzuweisen.

Spätestens seit das Konzept der permanenten Integration von Kent Beck im Rahmen von Extreme Programming populär gemacht wurde, ist der Begriff an sich bekannt, die Voraussetzungen sind allerdings oft nicht so klar.

Permanente Integration basiert auf der impliziten Annahme, dass das Projekt seine Quellen in einem zentralen Versionsverwaltungssystem verwaltet und diese auch zeitnah nach Bearbeitung wieder dort einstellt.

Auch wenn Systeme wie CruiseControl, Jenkins (ehemals Hudson) oder Anthill es sehr viel leichter machen, eine permanente Integration umzusetzen, so ist doch in vielen Unternehmen und Projekten keine Umgebung vorhanden, die ein solches Arbeiten unterstützt.

Die einfachere Alternative – und häufig die Vorstufe zur permanenten Integration – ist der Nightly Build (nächtlicher Erstellungsprozess), bei dem jede Nacht die aktuellen Versionen aus dem Versionsverwaltungssystem geholt werden und auf diesem Stand ein Gesamtsystem gebaut wird. Sofern möglich, wird auch noch eine Installation in der Zielumgebung vorgenommen (Deployment) und ein Minimaltest (Anschalttest, vgl. Smoke testing) durchgeführt.

Die Einführung permanenter Integration oder ersatzweise eines täglichen Builds ist ein geeigneter Weg, die Qualität zu steigern.

Vorteile

• Integrations-Probleme werden laufend entdeckt und behoben (gefixt) – nicht erst kurz vor einem Meilenstein
• frühe Warnungen bei nicht zusammenpassenden Bestandteilen
• sofortige Unit-Tests entdecken Fehler schnell
• konstante Verfügbarkeit eines lauffähigen Standes für Demo-, Test- oder Vertriebszwecke
• Die sofortige Reaktion des Systems auf das Einchecken fehlerhaften oder unvollständigen Codes „erzieht“ die Entwickler im positiven Sinne zu einem verantwortlicheren Umgang und kürzeren Checkin-Intervallen.

Bedingungen

Die folgenden Bedingungen entstammen einem Artikel^[1] von Martin Fowler.

Gemeinsame Codebasis

Um innerhalb eines Teams sinnvoll integrieren zu können, muss eine Versionsverwaltung existieren, in die alle Entwickler ihre Änderungen kontinuierlich integrieren können.

Automatisierte Übersetzung

Jede Integration muss einheitlich definierte Tests durchlaufen, bevor die Änderungen integriert werden. Dafür ist automatisierte Übersetzung notwendig.

Beispiele:

• Compilierung eines Produkts
• Statische Code-Überprüfungen
• Compilierung von Test-Systemen
• Ausführung von Test-Systemen
• Generierung von Dokumentation

Um Testergebnisse von den Arbeitsumgebungen unabhängig zu machen, empfiehlt sich der Einsatz von dedizierten Test-Rechnern. Damit können auf diesen Rechnern auch gezielt Verfahren implementiert werden, um die Testlaufzeit zu minimieren.

Kontinuierliche Test-Entwicklung

Jede Änderung sollte möglichst zeitgleich mit einem dazugehörigen Test entwickelt werden (Testgetriebene Entwicklung). Ist das nicht möglich, sollte zumindest eine zeitnahe Entwicklung von entsprechenden Tests angestrebt werden.

Neu entwickelte Tests sollten Bestandteil der automatisierten Test-Suite werden.

Mit Hilfe von kontrollflussorientierten Testverfahren (Code Coverage Analysis) kann diese Vorgehensweise dokumentiert und kontrolliert werden.

Häufige Integration

Jeder Entwickler sollte seine Änderungen so oft wie möglich in die gemeinsame Code-Basis integrieren. Mit kurzen Integrations-Intervallen erreicht man

• Risiko von fehlschlagenden Integrationen wird mit kleinen Inkrementen minimiert
• die Arbeit der Entwickler wird häufig in die gemeinsame Code-Basis gesichert (Backup)

Kurze Testzyklen

Der Test-Zyklus vor der Integration sollte kurz gehalten sein, um häufige Integrationen zu fördern. Mit steigenden Qualitätsanforderungen für die einzelnen Integrationen steigt auch die benötigte Zeit dieser Test-Zyklen. Hierbei muss immer sorgfältig abgewogen werden. Weniger relevante Tests werden dann verschoben und erst nach einzelnen Integrationen durchgeführt.

Gespiegelte Produktionsumgebung

Die Änderungen sollten in einem Abbild der realen Produktionsumgebung getestet werden.

Einfacher Zugriff

Auch Nicht-Entwickler brauchen einfachen Zugriff auf die Ergebnisse der Software-Entwicklung. Dies müssen nicht notwendigerweise Quellen sein. Sinnvoll sind hierbei

• fertig compiliertes Produkt für Tester
• Qualitäts-Zahlen für Qualitäts-Verantwortliche
• Dokumentation
• fertig paketiertes Abbild für Release Manager

Automatisiertes Reporting

Die Ergebnisse der Integrationen müssen leicht zugreifbar sein. Sowohl Entwickler als auch andere Beteiligte müssen leicht Informationen bekommen können

• wann wurde die letzte erfolgreiche Integration ausgeführt?
• welche Änderungen wurden seit der letzten Lieferung eingebracht?
• welche Qualität hat die Version?

Automatisierte Verteilung

Jede Version sollte leicht in eine Produktionsumgebung (oder ein Abbild derselbigen) überführt werden können. Hierfür sollte die Softwareverteilung automatisiert sein.

Software

Eine Liste verfügbarer Werkzeuge zur Unterstützung dieses Prozesses:

• AnthillPro – ein kommerzielles Werkzeug von Urbancode.
• Anthill ist die frei verfügbare Variante.
• LuntBuild – ein Werkzeug für Build und Management.
• Bamboo – ein kommerzieller Server für fortlaufende Integration von Atlassian
• Bitten – ein Plugin zur fortlaufenden Integration für Trac
• BuildBot – ein in Python/Twisted implementiertes System für kontinuierliche Erstellungsprozesse
• Build Forge – ein Framework der IBM-Tochtergesellschaft Rational Software, das die Build- und Release-Prozesse automatisieren soll
• CABIE – eine in Perl geschriebene Open-Source-Erstellungs- und Integrationsumgebung, die mit CVS, Subversion and Perforce ein Server für fortlaufende Integration, der Apache Maven und Apache Ant unterstützt
• Continuum - ein Subprojekt des Apache Maven Projekts. Unterstützt Maven 1, Maven 2, Ant und Shell-Skripte.
• CruiseControl – ein Java-basiertes Framework für kontinuierliche Erstellungsprozesse, Derivate auch für .NET und Ruby
• DamageControl – ein weiterer Continuous-Integration-Server für Ruby
• Apache Gump – ein Werkzeug für fortlaufende Integration der Apache Software Foundation
• Railsonfire - ein Webservice für automatische Integration von Ruby Programmen
• Jenkins – mit MIT-Lizenz, geschrieben in Java, läuft in Servlet-Container, unterstützt CVS, Subversion, Ant, Maven, und Shell-Skripte
• Team Foundation Server - eine Plattform für kollaborative Softwareprojekte auf Basis von Microsoft SQL Server und Windows SharePoint Services
• Tinderbox – ein auf Mozilla basierendes Produkt
• Teamcity – ein Werkzeug von JetBrains, Web-basiert, verträglich mit den integrierten Entwicklungsumgebungen IntelliJ IDEA, Eclipse und Microsoft Visual Studio
• Xinc – Continuous-Integration-Server für PHP-Anwendungen
• NabiCI - Lightweight Continuous Integration Framework für PHP-Projekte

Literatur

• Manfred Lange: Fortlaufende Integration. XP Exchange, 14. Januar 2002 (online, abgerufen am 13. April 2007).

Weblinks

• Multi-stage Continuous Integration von Damon Poole (englisch)
• Continuous integration von Martin Fowler (eine Einführung, englisch)
• Continuous Integration im Portland Pattern Repository (englisch)
• Continuous Integration Server Feature Matrix (Übersicht über diverse Werkzeuge, englisch)
• Continuous Integration: The Cornerstone of a Great Shop von Jared Richardson (Einführung auf englisch)
• Continuous Integration on a Dollar a Day von James Shore (Anleitung, englisch)
• A Recipe for Build Maintainability and Reusability von Jay Flowers (englisch)
• Erhöhung der Softwarequalität in kleinen Unternehmen durch einen Continuous Integration-Prozess von Martin Rödig (Diplomarbeit mit umfangreicher Tool-Marktübersicht, deutsch)

Einzelnachweise

1. ↑ ^{a b} FOWLER, Martin. Continuous Integration (Englisch)