Was wir gemeinsam aufgebaut haben: Ein praktisches Verständnis von CI/CD

Es begann mit einer einfachen Frage: Wie bringt man Änderungen an der Anwendung, der Datenbank und der Infrastruktur dorthin, wo die Leute sie tatsächlich nutzen, ohne deren Erlebnis zu beeinträchtigen?

Diese Frage ist schwieriger, als sie klingt. Jedes Team, mit dem ich gearbeitet habe, hat die Spannung zwischen schnellem und sicherem Ausliefern gespürt. Manche Teams lösen das mit aufwändigen Zeremonien. Andere mit Skripten, die nur eine Person versteht. Keiner der Ansätze skaliert, und beide erzeugen bei jedem Deployment Angst.

Dieser Beitrag führt durch die Grundlage, die wir im Buch gemeinsam aufgebaut haben. Es ist keine Zusammenfassung der Kapitel. Es ist eine Karte, wie die Teile zusammenpassen, wenn man CI/CD nicht mehr als Werkzeug, sondern als Fähigkeit betrachtet.

Beginne mit dem Deployment, nicht mit der Pipeline

Bevor du etwas automatisieren kannst, musst du verstehen, was Deployment eigentlich bedeutet. Deployment ist der Vorgang, eine neue Version von etwas in eine Umgebung zu bringen, in der Nutzer darauf zugreifen können. Das klingt offensichtlich, aber die Auswirkungen sind es nicht.

Wenn du eine schlechte Version einer Anwendung deployst, kannst du sie komplett ersetzen. Wenn du eine schlechte Datenbankmigration deployst, sind die Daten noch da, und ein Rollback ist komplexer. Wenn du Infrastrukturänderungen deployst, die das Netzwerk lahmlegen, funktioniert nichts mehr.

Diese drei Dinge – Anwendungen, Datenbanken und Infrastruktur – können nicht gleich behandelt werden. Jedes hat seine eigene Deployment-Strategie. Anwendungen funktionieren gut mit Blue-Green-Deployment, bei dem du den Traffic zwischen zwei identischen Umgebungen umschaltest. Datenbanken benötigen eine schrittweise Migration, bei der Änderungen in kleinen, umkehrbaren Schritten angewendet werden. Infrastruktur profitiert von einem immutable Ansatz, bei dem du ganze Umgebungen ersetzt, anstatt sie zu patchen.

Das folgende Diagramm zeigt die drei parallelen Spuren und ihre empfohlenen Strategien:

flowchart TD subgraph Application A1[New Version] --> A2[Blue-Green Deploy] A2 --> A3[Switch Traffic] A3 --> A4[Rollback if needed] end subgraph Database D1[Change] --> D2[Gradual Migration] D2 --> D3[Small Reversible Steps] D3 --> D4[Rollback Scripts] end subgraph Infrastructure I1[Config Change] --> I2[Immutable Replace] I2 --> I3[Replace Entire Environment] I3 --> I4[No Patching] end A1 -.->|different strategies| D1 D1 -.->|different strategies| I1

Es geht nicht darum, diese Strategien auswendig zu lernen. Es geht darum zu erkennen, dass Deployment keine einzelne Aktion ist. Es ist eine Reihe von Entscheidungen darüber, wie Änderungen sicher bewegt werden, und diese Entscheidungen hängen davon ab, was du bewegst.

Pipeline als Vertrag, nicht als Skript

Sobald du Deployment verstehst, kannst du eine Pipeline bauen. Aber eine Pipeline ist kein Skript, das Befehle ausführt. Eine Pipeline ist ein Vertrag, dass jede Änderung dieselben Prüfungen in derselben Reihenfolge in einer konsistenten Umgebung durchlaufen muss, bevor sie in die Produktion gelangt.

Diese Unterscheidung ist wichtig, weil Teams Pipelines oft als Automatisierung ihres bestehenden manuellen Prozesses behandeln. Wenn der manuelle Prozess Lücken hat, automatisiert die Pipeline diese Lücken ebenfalls. Eine gute Pipeline beginnt mit der Frage: Was muss über eine Änderung wahr sein, bevor sie zu den Nutzern gelangt?

Bei Anwendungsänderungen könnte die Antwort das Bestehen von Unit-Tests, Integrationstests und Sicherheitsscans umfassen. Bei Datenbankänderungen könnte es die Überprüfung beinhalten, dass Migrationen umkehrbar sind und Rollback-Skripte existieren. Bei Infrastrukturänderungen könnte es die Durchführung einer Validierung in einer Live-Staging-Umgebung umfassen.

Eine Pipeline für alle drei Arten von Änderungen gleichzeitig zu bauen, ist die eigentliche Herausforderung. Die meisten Teams beginnen mit einer und fügen die anderen später hinzu. Das ist in Ordnung, solange du weißt, welche du vermisst und warum.

Deploy ist nicht Release

Eine der nützlichsten Unterscheidungen im Buch ist die Trennung von Deploy und Release.

Deploy bedeutet, eine neue Version auf den Server zu bringen. Release bedeutet, dass diese Version tatsächlich von den Nutzern verwendet wird. Wenn du diese beiden Aktionen trennst, gewinnst du Kontrolle über das Risiko. Du kannst eine Version deployen, sie in der Produktion mit internen Nutzern testen und sie erst für alle freigeben, wenn du sicher bist.

Diese Trennung ermöglicht Strategien wie Feature Flags, Canary Releases und Progressive Delivery. Feature Flags erlauben es dir, Funktionen ein- und auszuschalten, ohne neu zu deployen. Canary Releases leiten zunächst einen kleinen Prozentsatz des Traffics auf die neue Version. Progressive Delivery erhöht diesen Prozentsatz schrittweise, während du Metriken beobachtest.

Keine dieser Strategien erfordert ein bestimmtes Tool. Sie erfordern eine Denkweise, die Deployment und Release als separate Entscheidungen behandelt, jede mit ihrem eigenen Risikoprofil.

Plattform-Engineering als Beschleuniger

Wenn mehrere Teams Änderungen durch Pipelines ausliefern, zeigen sich Muster. Jedes Team braucht dieselben grundlegenden Dinge: eine Möglichkeit, Änderungen zu bauen, zu testen und zu deployen; konsistente Umgebungen für diese Tests; und Self-Service-Zugriff auf die Infrastruktur.

Plattform-Engineering ist die Praxis, diese Fähigkeiten als interne Produkte aufzubauen. Eine Plattform ist kein großes Projekt, das abgeschlossen sein muss, bevor jemand sie nutzt. Eine Plattform beginnt mit einem echten Bedarf eines Teams, löst ihn gut und erweitert sich dann, wenn weitere Bedürfnisse auftauchen.

Die entscheidende Erkenntnis hier ist, dass es beim Plattform-Engineering nicht darum geht, die perfekte Abstraktion zu bauen. Es geht darum, die kognitive Last der Teams zu reduzieren, damit sie sich auf die Wertschöpfung konzentrieren können. Wenn ein Team zwei Tage braucht, um eine Pipeline einzurichten, funktioniert die Plattform nicht. Wenn sie einen neuen Dienst mit einem einzigen Pull Request hochziehen können, funktioniert die Plattform.

Governance als Leitplanken, nicht als Tore

Governance wird oft als eine Schicht missverstanden, die Dinge verlangsamt. In der Praxis geht es bei Governance in CI/CD darum, Grenzen zu setzen, die es Teams ermöglichen, schnell zu handeln, ohne etwas zu beschädigen.

Review-Richtlinien für Produktionsänderungen, automatisierte Audit-Trails und risikobasierte Deployment-Regeln dienen alle demselben Zweck: Sie schaffen einen klaren Pfad für Änderungen, sodass Teams nicht raten müssen, was erlaubt ist, oder jedes Mal auf manuelle Genehmigung warten müssen.

Der Unterschied zwischen Governance als Tor und Governance als Leitplanke ist subtil, aber wichtig. Ein Tor blockiert Änderungen, bis jemand sie genehmigt. Eine Leitplanke definiert den sicheren Pfad und lässt Teams sich darin frei bewegen. Ersteres schafft Engpässe. Letzteres schafft Autonomie.

Eine praktische Checkliste

Wenn du CI/CD-Fähigkeiten in deiner Organisation aufbaust, hier eine kurze Checkliste, um deine Entscheidungen zu leiten:

  • Kannst du eine Änderung ohne manuelle Schritte in die Produktion deployen?
  • Kannst du ein Deployment in unter fünf Minuten zurückrollen?
  • Kennst du den Unterschied zwischen deiner Deploy-Strategie und deiner Release-Strategie?
  • Durchläuft jede Änderung dieselben Prüfungen, unabhängig davon, wer sie erstellt hat?
  • Kann ein neues Teammitglied am ersten Tag sein erstes Deployment durchführen, ohne um Berechtigungen bitten zu müssen?
  • Hast du eine Möglichkeit, Datenbankmigrationen zu testen, bevor sie in die Produktion gelangen?
  • Wird deine Infrastruktur als Code behandelt und nicht als Snowflake-Server?

Wenn du eine dieser Fragen mit Nein beantwortet hast, weißt du, worauf du dich als Nächstes konzentrieren solltest.

CI/CD ist eine Fähigkeit, die du pflegst

Die wichtigste Lektion aus dieser Reise ist, dass CI/CD kein Projekt ist, das du abschließt. Es ist eine Fähigkeit, die du pflegst. Werkzeuge ändern sich. Teams wachsen. Anforderungen verschieben sich. Die Praktiken, die heute funktionieren, funktionieren vielleicht nächstes Jahr nicht mehr.

Was konstant bleibt, ist das Verständnis, dass sicheres Ausliefern von Änderungen eine Fähigkeit ist, kein Skript. Es wird aus kleinen Entscheidungen aufgebaut, die jeden Tag getroffen werden: wie du deine Tests strukturierst, wie du mit Fehlern umgehst, wie du Geschwindigkeit und Sicherheit ausbalancierst. Diese Entscheidungen summieren sich im Laufe der Zeit und bestimmen, ob dein Team mit Zuversicht oder mit Angst ausliefert.

Beginne mit einer Änderung. Mache sie sicher. Dann mache sie wiederholbar. Dann mache sie schnell. Der Rest wird folgen.