DevOps wird oft mit einer Werkzeugliste verwechselt. Der eigentliche Kern ist eine organisatorische Entscheidung: Wer Software baut, verantwortet auch ihren Betrieb.
Klassisch waren Entwicklung und Betrieb getrennt. Die Entwicklung lieferte ein Paket ab, der Betrieb brachte es zum Laufen und war anschließend für Störungen zuständig. Diese Trennung erzeugte gegenläufige Ziele: Entwicklung wurde an Änderungen gemessen, Betrieb an Stabilität. Änderungen sind aber die häufigste Ursache für Instabilität.
Der Kern von DevOps
DevOps löst diesen Zielkonflikt, indem es die Verantwortung zusammenführt. Ein Team ist für Entwicklung und Betrieb eines Dienstes zuständig. Die Rückmeldung aus dem Betrieb erreicht damit direkt diejenigen, die etwas ändern können. Die bekannten Werkzeuge sind Folge dieser Entscheidung, nicht ihre Ursache. Wer die Werkzeuge einführt, ohne die Verantwortung zu ändern, hat lediglich neue Werkzeuge.
Vier Praktiken tragen den Ansatz: kleine, häufige Änderungen statt großer Auslieferungen; Automatisierung wiederkehrender Schritte; Infrastruktur als versionierter Code; und Messbarkeit über Protokolle und Metriken.
Versionskontrolle als Fundament
Ohne saubere Versionskontrolle funktioniert keine Automatisierung. Git hat sich als Standard durchgesetzt, weil es verteilt arbeitet: Jede Kopie enthält die vollständige Historie, Verzweigungen sind billig, und paralleles Arbeiten ist der Normalfall statt der Ausnahme.
Wichtiger als das Werkzeug ist die vereinbarte Arbeitsweise. Ein einfaches Modell mit einem stets auslieferbaren Hauptzweig und kurzlebigen Feature-Zweigen passt zu häufigen Auslieferungen. Aufwendigere Modelle mit langlebigen Entwicklungs- und Release-Zweigen passen zu Software mit festen Versionsständen. Der häufigste Fehler ist ein Modell, das nicht zum Auslieferungsrhythmus passt: Langlebige Zweige und tägliche Auslieferung erzeugen dauerhaft schmerzhafte Zusammenführungen.
Zwei Regeln sparen viel Ärger: Zugangsdaten gehören niemals ins Repository, auch nicht in der Historie, und der Hauptzweig bleibt jederzeit auslieferbar.
Wie eine Pipeline aufgebaut ist
Continuous Integration bedeutet, dass Änderungen mehrmals täglich zusammengeführt und automatisch geprüft werden. Continuous Delivery bedeutet, dass jeder geprüfte Stand jederzeit ausgeliefert werden könnte. Continuous Deployment geht einen Schritt weiter und liefert automatisch aus.
Eine typische Pipeline durchläuft:
- Auslöser. Eine Änderung im Repository startet den Lauf.
- Bauen. Aus dem Quellcode entsteht ein Artefakt, genau einmal. Dasselbe Artefakt durchläuft danach alle Stufen, damit getestet wird, was auch ausgeliefert wird.
- Schnelle Tests. Unit-Tests und statische Codeprüfung, Laufzeit möglichst unter zehn Minuten.
- Sicherheitsprüfungen. Abhängigkeiten auf bekannte Schwachstellen prüfen, Suche nach versehentlich eingecheckten Zugangsdaten.
- Langsamere Tests. Integrations- und Oberflächentests in einer produktionsnahen Umgebung.
- Ausliefern. Zuerst in eine Vorstufe, nach Freigabe in die Produktion.
Die Reihenfolge folgt einem Prinzip: schnelle und häufig fehlschlagende Prüfungen zuerst. Eine Pipeline, die eine Stunde läuft, bevor sie einen Tippfehler meldet, wird umgangen. Welche Testarten dabei sinnvoll kombiniert werden, beschreibt der Artikel zu Softwaretests.
Auslieferungsstrategien
Wie eine neue Version in Produktion geht, entscheidet über das Risiko:
- Rollierende Aktualisierung. Instanzen werden nacheinander ersetzt. Kein zusätzlicher Bedarf an Ressourcen, aber zwei Versionen laufen zeitweise parallel.
- Blau-Grün. Zwei vollständige Umgebungen, der Verkehr wird umgeschaltet. Sofortige Rückkehr möglich, dafür doppelter Ressourcenbedarf.
- Schrittweise Freigabe. Zuerst ein kleiner Anteil der Nutzer, bei stabilen Werten schrittweise mehr. Begrenzt den Schaden eines Fehlers wirksam, setzt aber gute Messwerte voraus.
In allen Fällen gilt: Der Rückweg muss vor der Auslieferung getestet sein. Besonders Datenbankänderungen sind selten einfach rückgängig zu machen, weshalb Schemaänderungen abwärtskompatibel gestaltet werden sollten.
Sicherheit im Prozess statt danach
Sicherheitsprüfungen erst kurz vor dem Auslieferungstermin führen dazu, dass Funde aus Termingründen verschoben werden. Sinnvoller ist die Integration in die Pipeline: automatische Prüfung der Abhängigkeiten auf bekannte Schwachstellen, statische Analyse des Codes, Suche nach Zugangsdaten im Repository und Prüfung der Container-Grundlagen. Zugangsdaten gehören in einen dedizierten Speicher und werden zur Laufzeit eingebunden. Warum das ins größere Bild passt, zeigt der Artikel zu Zero Trust.
Woran sich Fortschritt messen lässt
Vier Kennzahlen haben sich etabliert: Wie häufig wird ausgeliefert? Wie lange dauert es von der fertigen Änderung bis zur Produktion? Wie oft verursacht eine Auslieferung eine Störung? Wie lange dauert die Wiederherstellung? Leistungsfähige Teams sind nicht deshalb schneller, weil sie sorgloser arbeiten, sondern weil kleine Änderungen leichter zu prüfen und zurückzunehmen sind.
Der Betrieb solcher Pipelines findet meist auf Cloud-Infrastruktur statt, die Grundlagen dazu stehen in der Übersicht zu Cloud Computing. Viele der eingesetzten Werkzeuge sind quelloffen, siehe Open Source verstehen.
Häufige Fragen
Was ist der Unterschied zwischen Continuous Delivery und Continuous Deployment?
Bei Continuous Delivery ist jeder geprüfte Stand jederzeit auslieferbar, die Freigabe erfolgt aber manuell. Bei Continuous Deployment wird jeder erfolgreich geprüfte Stand automatisch in Produktion gebracht.
Reicht es, DevOps-Werkzeuge einzuführen?
Nein. Der Kern von DevOps ist die gemeinsame Verantwortung eines Teams für Entwicklung und Betrieb. Wer nur die Werkzeuge einführt, ohne die Verantwortung zu ändern, hat lediglich neue Werkzeuge.
Wie lang darf eine CI-Pipeline laufen?
Die schnellen Prüfungen sollten unter zehn Minuten bleiben. Pipelines, die eine Stunde brauchen, bevor sie einen einfachen Fehler melden, werden in der Praxis umgangen.