Ein Angebot von

Wie erreicht man Continuous Integration?

| Autor / Redakteur: Brian Dawson * / Stephan Augsten

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)

Viele Entwickler glaubten, dass sie Continuous Integration (CI) 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?

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.

Brian Dawson
Brian Dawson (Bild: CloudBees)

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.

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.

Safe Continuous Integration

Safe Continuous Integration

12.06.17 - Ein manueller Software-Integrationsprozess kann nicht immer mit der Geschwindigkeit der Änderungen in der Entwicklung mithalten. Deshalb gehen mehr und mehr Hersteller dazu über, einen Continuous Integration (CI) Prozess aufzusetzen: Build-Zyklen erfolgen früh und iterativ zusammen mit automatisierten Tests. lesen

5 Best Practices für Continuous Delivery bei der Embedded-Entwicklung

5 Best Practices für Continuous Delivery bei der Embedded-Entwicklung

22.11.17 - Versäumte Liefertermine oder mangelnde Qualität werden in der Embedded-Branche immer seltener toleriert. Hilfe verspricht hier die Entwicklungsmethode Continuous Delivery. lesen

Warum Modultests unbeliebt sind und wie man sie rehabilitieren kann

Warum Modultests unbeliebt sind und wie man sie rehabilitieren kann

05.02.18 - Für die meisten Entwickler sind Modultests nicht mehr als ein unvermeidbares Übel, das man einfach hinter sich bringen muss. Warum ist das so, und wie kann Softwareautomation Abhilfe bieten? lesen

Dieser Beitrat stammt von unserer Partnerplattform Dev-Insider.de.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45269724 / Agilität)