Suchen

Tools sind kein Erfolgsgarant Wie erreicht man Continuous Integration?

| Autor / Redakteur: Brian Dawson * / Stephan Augsten

Viele Entwickler glaubten dass sie CI, also Continuous Integration anwenden. Folgende Fragen müssten sie dann einfach beantworten können: Lässt sich ein Softwareproblem in weniger als zehn Minuten beheben? Befüllen sie die Haupt-Pipeline ihrer Organisation regelmäßig mit Builds?

Firmen zum Thema

Lassen sich CI-Maßnahmen nicht vernünftig umsetzen, liegt oft ein kulturelles Problem innerhalb der Organisation vor.
Lassen sich CI-Maßnahmen nicht vernünftig umsetzen, liegt oft ein kulturelles Problem innerhalb der Organisation vor.
(© magele-picture - stock.adobe.com)

Continuous Delivery (CD) und DevOps verändern den Markt drastisch und verschaffen Unternehmen enorme Wettbewerbsvorteile. CD basiert auf der bewährten Praxis von Continuous Integration. Unternehmen müssen also zunächst das Konzept der CI vollständig in allen Facetten verstehen und auch leben – und es nicht nach Belieben so umdefinieren, um genau das abzudecken, was sie ohnehin schon tun.

Kontinuierliche Integration ist kein einfaches Thema. Alle Firmen und Organisationen, die CI korrekt durchführen, befolgen einige Grundregeln: Die Arbeitskopien der Entwickler werden mindestens täglich, vorzugsweise mehrmals täglich, mit einer gemeinsamen sogenannten Mainline synchronisiert. Jede Integration wird durch einen automatisierten Build verifiziert, um Fehler so schnell wie möglich zu erkennen.

Unternehmen und Entwickler, die diese Schritte nicht befolgen, setzen Maßnahmen von CI nicht richtig um. Oft liegt ein kulturelles Problem innerhalb der Organisation vor. Ingenieure sind zwar gut darin, technische Probleme zu lösen. Aber CI erfordert einen echten Kulturwandel. Die alleinige Einführung eines CI-Tools ist noch kein Erfolgsgarant. Auch die Art und Weise, wie die gesamte Organisation und die einzelnen Teams zusammenarbeiten, muss sich für CI ändern.

Eines muss zunächst aber klar sein: CI-Prozesse sind nicht darauf ausgelegt, Fehler zu eliminieren. Im Gegenteil: CI selbst ist ein Prozess, der darauf ausgerichtet ist, für Fehler offen zu sein. Ziel ist es, ein System zu schaffen, in dem Entwickler Fehler unterlaufen dürfen, diese aber schnell erkannt und so zeitnah behoben werden können.

Die Grundprinzipien und Praktiken von CI reichen mindestens 15 Jahre zurück, als Martin Fowler den Begriff einführte. Um CI richtig umzusetzen, gilt es, folgende Regeln zu beachten:

  • Verpflichtung zur Mainline: Diese Regel ist ein Grundpfeiler für die CI. Ein Entwickler kann einen automatisierten Build einrichten und den Build mit jedem Commit ausführen lassen. Aber wenn die Kultur innerhalb der Organisation nicht ‚Commit-friendly‘ ist, gibt es keinen Mehrwert. Wenn ein Entwickler drei Wochen für ein Commit benötigt oder in eine andere Richtung lenkt, hat er die Integration verzögert und die Prinzipien missachtet. Bricht ein Build, muss das Team Wochen lang daran arbeiten, um herauszufinden, an welcher Stelle genau der Build gebrochen wurde.
  • Beibehaltung eines Single-Source-Repository: In komplexen Anwendungen nehmen Entwickler Änderungen häufig von einem „Trunk” oder einem „Main” ausgehenden Klon vor. Diese sogenannte „Branch” schafft Komplexität und verhindert, dass alle an einer Single-Source-of-Truth arbeiten. Teams müssen mindestens einmal pro Tag – oder noch besser – bei jeder Änderung in den Trunk oder die Main einarbeiten.
  • Automatisieren des Build: Dies ist eine Vorgehensweise, die die meisten Unternehmen gut beherrschen. Einige jedoch, die behaupten, CI zu praktizieren, arbeiten mit geplanten (bspw. „nightly“) oder kontinuierlichen Builds – ohne diese nach jeder Anpassung oder Änderung zu testen. Doch ohne Validierung und Testen des Builds erfolgt keine Continuous Integration.
  • Testen des Build: Der erste Schritt des Validierungsprozesses ist die Kenntnis, dass ein Build mit Problemen tatsächlich fehlgeschlagen ist. Der nächste Schritt besteht darin, festzustellen, ob das Produkt des Builds funktionsfähig ist und ob es funktioniert wie erwartet. Diese Tests, sowohl schnelle funktionale als auch nicht-funktionale, sollten fester Bestandteil des Build-Prozesses sein.
  • Schnelligkeit zählt: Wenn es zu lange für den Buildserver dauert, eine Anwendung zu erstellen, werden Entwickler Änderungen nur zögerlich committen oder es wird am Ende eine große Anzahl an Änderungen geben. In beiden Fällen sinkt die Wahrscheinlichkeit, Fehler schnell zu erkennen.
  • Test an einem realitätsgetreuen Klon: Validierungsprozesse stellen sicher, dass die Software in ihrer vorgesehenen Umgebung wie erwartet funktioniert. Wenn Sie in einer anderen Umgebung testen, kann dies zu falschen Ergebnissen führen.
  • Unmittelbare Fehlerbehebung fehlerhafter Builds: Vor Jahren führte Toyota einen „Stop-the-Line“-Ansatz ein. Mitarbeiter erhielten die Ermächtigung, den Produktionsprozess sofort zu stoppen, sollten sie ein Problem entdecken. Gleiches gilt für Entwicklerteams: Ihre Aufgabe ist es, Probleme schnell zu finden und sofort zu beheben. CI fördert Prozesse, in denen Builds kontinuierlich validiert und committed werden, um Fehler einfach und schnell beheben zu können.

Bildlich gesprochen ist CI wie ein Regenmantel über einem teuren Anzug. Entwickler versprechen schnelle Liefertermine für die neue Version einer App, weil sie sich darauf verlassen können, dass ihr Mantel – also ihre CI-Prinzipien – das Projekt schützt. Ist der Regenmantel nicht dicht, ist auch das Anzug darunter betroffen. Das Gleiche gilt für CI.

Brian Dawson
Brian Dawson
(Bild: CloudBees)

Viele Organisationen arbeiten hart daran, CI zu implementieren und damit ihre DevOps-Praktiken zu verbessern. Das größte Hindernis für eine makellose CI sind nach wie vor unsere Kultur und unser Festhalten an alten Technologien und Prozesse. Sie sind Feind des Wandels.

* Brian Dawson ist DevOps Evangelist bei CloudBees.

(ID:45253334)