Continuous Integration

Continuous Integration ist eine Softwareentwicklungspraxis, bei der die Mitglieder eines Entwicklungsteams ihren Softwarestand regelmäßig und automatisiert mit dem Stand der anderen Teammitglieder in einen gemeinsamen Softwarestand integrieren. Bei dieser Integration wird geprüft, ob der aus allen Ständen gebildete Code zusammenpasst, ob alle Tests fehlerfrei durchlaufen und ob aus dem gemeinsamen Softwarestand ein Artefakt gebaut werden kann.

Prinzipien kontinuierlicher Integration

Die am weitesten verbreitete der Umsetzung geht von einem zentralen Integrationsserver aus, der bei jedem Commit in das Versionsverwaltungssystem den aktuellsten Softwarestand herunterlädt, daraus das Softwaresystem baut und alle Tests ausführt. Der gesamte Prozess sollte nicht länger als 10 Minuten dauern, damit das Feedback des Integrationsservers wertvoll für das Team ist.

Implementierungen

Es gibt eine Vielzahl von fertigen Softwarelösungen, die die das Aufsetzen eines Integrationsservers beschleunigen sollen. Die bekannteste Software in diesem Bereich ist der Automatisierungsserver Jenkins. Die einfachste Variante von Continuous Integration mit dem Namen “Continuous Integration on a Dollar a Day” kommt sogar ganz ohne Toolunterstützung aus, so dass man sofort loslegen kann:

  1. Lokal bauen bis grün: Prüfe deine Änderungen am Code lokal. Ist der Build erfolgreich? Laufen alle Tests noch? Committe deine Änderungen (git commit).
  2. Integrationstoken reservieren: Nimm dir das Build-Maskottchen. Integrieren darf nur, wer dieses Token besitzt. Damit verhinderst du, dass sich Integrationen gegenseitig behindern und du unnötig mergen musst.
  3. Lokal integrieren bis grün: Hole die letzten Updates aus der Quellcodeverwaltung (git update). Damit stellst du sicher, dass du keine Änderungen deiner Teammit- glieder verpasst. Prüfe, ob der Build lokal durchläuft. Sind deine Änderungen mit den Änderungen der Teammitglieder kompatibel? Laufen noch immer alle Tests?
  4. Einchecken: Bringe deine Änderungen in die Quellcode- verwaltung (git push).
  5. Auf Integrationsserver integrieren bis grün: Aktualisiere die Workarea auf dem Integrations- rechner. Starte dort den Build. Ist alles noch grün, laufen alle Tests? Hast du alles eingecheckt?
  6. Bescheid geben: Gib das Integrationstoken frei und informiere deine Teammitglieder über deine Änderungen. Diese können jetzt ihre Arbeitsumgebungen aktualisieren, um auf dem neuesten Stand zu arbeiten und Merges zu verringern.
  7. Ausliefern (optional): Alle Änderungen sind integriert, der Build ist er- folgreich und alle Tests laufen. Warum nicht gleich ausliefern? Frühes Feedback ist wiCchotimg umnidtzeigt uns, ob wir auf dem richtigen Weg sind.

Vorteile von Continuous Integration

Schnelles Feedback

Je länger es dauert, bis die Mitglieder eines Entwicklungsteam ihre Softwarestände integrieren, desto schwieriger und desto länger wird die Integration werden. Im Umkehrschluss gilt somit: Je häufiger die Softwarestände integriert werden, desto seltener und weniger umfangreich können Probleme beim Synchronisieren der Softwarestände auftreten.

Erhöhte Transparenz

Der Software wird an einem Ort zusammengeführt, der die zentrale Wahrheit über den aktuellen Stand der Softwareentwicklung darstellt. Dieser zentralen Stand kann sehr gut visualisiert werden. So gibt es Build-Ampeln, die grün leuchten, wenn das letze Softwareinkrement fehlerfrei getestet und erfolgreich gebaut wurde. Alternativ kann man auf Build-Monitoren die gesamte Strecke vom Bau der Software, über den Stand der Unit-Tests bis hin zur Durchführung der Akzeptanztests visualisieren. Tritt auf einer Teilstrecke ein Fehler auf, so sieht man auf den ersten Blick, wo die möglichen Fehlerquellen liegen.

Bessere Qualität

Der zentrale Stand der Anwendung wird stets durch den Integrationsserver getestet. Im Vergleich zu Entwicklern vergisst dieser niemals alle vorhandenen Tests auszuführen. Wenn das Team für eine hohe Testabdeckung des Source Codes sorgt und vom Integrationsserver gemeldete Fehler direkt vom Team behoben werden, führt das zu der hohen Qualität der Software, die durch agile Softwareentwicklung bedingt wird.

Erhöhte Geschwindigkeit durch Sicherheit

Dank der besseren Qualität und der erhöhten Sicherheit können Änderungen schneller und mutiger durchgeführt werden. Die in der agilen Softwareentwicklung notwendige Vorgehensweise des kontinuierlichen Refactorings wird dadurch ermöglicht. Dadurch entsteht eine Feedbackschleife, in der sich die Qualität, Sicherheit und Geschwindigkeit positiv verstärken.