Kontinuierliche Integration

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Kontinuierliche Integration (auch fortlaufende oder permanente Integration; englisch continuous integration) ist ein Begriff aus der Software-Entwicklung, der den Prozess des fortlaufenden Zusammenfügens von Komponenten zu einer Anwendung beschreibt. Das Ziel der kontinuierlichen Integration ist die Steigerung der Softwarequalität. Typische Aktionen sind das Übersetzen und Linken der Anwendungsteile, prinzipiell können aber auch beliebige andere Operationen zur Erzeugung abgeleiteter Informationen durchgeführt werden. Üblicherweise wird dafür nicht nur das Gesamtsystem neu gebaut, sondern es werden auch automatisierte Tests durchgeführt und Softwaremetriken erstellt. Der gesamte Vorgang wird automatisch ausgelöst durch Einchecken in die Versionsverwaltung.

Eine vereinfachte Variante der kontinuierlichen Integration – und häufig ihre Vorstufe – ist der Nightly Build (nächtlicher Erstellungsprozess). In der Praxis trifft man auch auf kontinuierliche Integration, gepaart mit einem Nightly Build, um die Vorteile beider Systeme zu kombinieren.

Eine Weiterentwicklung der kontinuierlichen Integration stellt die kontinuierliche Auslieferung (Continuous Delivery) dar. Dabei wird in bestimmten Zeitabständen oder bei Erreichen einer bestimmten Qualitätsmetrik eine neue Version der Software ausgeliefert.

Grundsätze[Bearbeiten]

Spätestens seit das Konzept der permanenten Integration von Kent Beck im Rahmen von Extreme Programming populär gemacht wurde, ist der Begriff der kontinuierlichen Integration an sich bekannt, für die erfolgreiche Einführung müssen allerdings einige Grundsätze (vgl. "Continuous Integration"[1] von Martin Fowler) befolgt werden:

Gemeinsame Codebasis
Um innerhalb einer Arbeitsgruppe 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 wie statische Code-Überprüfungen durchlaufen, bevor die Änderungen integriert werden. Dafür ist eine automatisierte Übersetzung notwendig.
Um Testergebnisse von den Arbeitsumgebungen unabhängig zu machen, empfiehlt sich der Einsatz von separaten Test-Umgebungen. 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 (beispielsweise mittels testgetriebener Entwicklung). Mit Hilfe von kontrollflussorientierten Testverfahren (Analyse der Code-Überdeckung, engl.: "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 reduziert man das Risiko fehlschlagender Integrationen und sichert gleichzeitig den Arbeitsfortschritt der Entwickler in der gemeinsamen Code-Basis (Datensicherung, engl: "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 Laufzeit zur Ausführung der Test-Zyklen. Die Menge der vor der Integration durchgeführten Tests muss sorgfältig abgewogen werden, weniger wichtige Tests werden dann nur nach der Integration 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, sondern kann beispielsweise das in das Testsystem gespielte Produkt für Tester, die Qualitäts-Zahlen für Qualitäts-Verantwortliche, die Dokumentation oder ein fertig paketiertes Abbild für Release Manager sein.
Automatisiertes Reporting
Die Ergebnisse der Integrationen müssen leicht zugreifbar sein. Sowohl Entwickler als auch andere Beteiligte müssen leicht Informationen darüber bekommen können, wann die letzte erfolgreiche Integration ausgeführt wurde, welche Änderungen seit der letzten Lieferung eingebracht wurden und welche Qualität die Version hat.
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.

Kontinuierliche Integration kann auf jedem Rechner mit Zugang zum Quellcode gemacht werden. Es ist insbesondere möglich, die Integration gleichzeitig auf unterschiedlichen Systemen (etwa verschiedenen Betriebssystemen) durchzuführen.

Vorteile[Bearbeiten]

  • 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 zeitnah
  • ständige 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.

Software[Bearbeiten]

Verfügbare Werkzeuge für kontinuierliche Integration:

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. FOWLER, Martin. Continuous Integration (englisch)