Fang morgen früh mit einer kleinen Änderung an

Du hast gerade das Kapitel über CI/CD, Delivery-Pipelines, interne Plattformen und kontinuierliche Verbesserung gelesen. Es klingt großartig. Aber wenn du auf dein eigenes Team schaust, fühlt sich die Lücke zwischen dem, was du gelesen hast, und dem, was du tatsächlich tust, riesig an.

Vielleicht läuft dein Build-Prozess immer noch auf dem Laptop eines Entwicklers. Vielleicht existiert deine Release-Checkliste nur im Kopf einer Person. Vielleicht ist deine Staging-Umgebung so weit von der Produktion abgewichen, dass ein Deployment sich wie Glücksspiel anfühlt. Vielleicht hast du noch nicht einmal ein Team – nur dich und eine Idee.

Diese Lücke ist normal. Jedes Team, das heute zuverlässig ausliefert, hat genau dort angefangen, wo du jetzt stehst. Sie sind nicht eines Morgens aufgewacht und hatten eine perfekte Pipeline, die zehnmal am Tag ohne Fehler deployed. Sie haben sie Schritt für Schritt aufgebaut, eine kleine Änderung nach der anderen.

Der wahre Startpunkt

Die meisten Teams haben kein Delivery-Problem, das eine große Neugestaltung erfordert. Sie haben einen einzigen Schritt in ihrem aktuellen Prozess, der am meisten wehtut. Genau dort fängst du an.

Schau dir an, wie dein Team heute eine Änderung ausliefert. Vom Moment, in dem jemand Code schreibt, bis zu dem Moment, in dem Benutzer die neue Version nutzen, liste jeden Schritt auf. Sei ehrlich darüber, was tatsächlich passiert, nicht was passieren sollte.

  • Wer führt den Build aus?
  • Woher weißt du, dass der Build erfolgreich war?
  • Was passiert, wenn ein Test fehlschlägt?
  • Wer entscheidet, dass es sicher ist zu deployen?
  • Wie bringst du die neue Version tatsächlich in die Produktion?
  • Woher weißt du, dass sie läuft, sobald sie dort ist?

Irgendwo in dieser Liste gibt es einen Schritt, der davon abhängt, dass eine Person sich daran erinnert, etwas zu tun. Irgendwo gibt es einen Schritt, der nicht zweimal auf die gleiche Weise wiederholt werden kann. Irgendwo gibt es einen Schritt, der die Leute vor jedem Release nervös macht.

Wähle diesen Schritt. Nur einen.

Wie eine einzelne Änderung aussieht

Nehmen wir an, der Build läuft immer noch auf dem Rechner eines Entwicklers. Wenn dieser Entwickler im Urlaub ist, kann niemand bauen. Wenn er eine leicht andere Bibliotheksversion verwendet, verhält sich der Build anders. Wenn der Laptop mitten im Build den Geist aufgibt, wartet das Team.

Hier ist ein minimales Beispiel, wie dieses Skript aussehen könnte:

#!/bin/bash
set -e

echo "Repository wird geklont..."
git clone https://github.com/your-org/your-app.git
cd your-app

echo "Abhängigkeiten werden installiert..."
npm install

echo "Build wird ausgeführt..."
npm run build

echo "Build erfolgreich!"

Speichere dies als build.sh, checke es in dein Repository ein und führe es von einem gemeinsamen Server oder CI-Dienst aus. Jetzt kann jeder einen wiederholbaren Build auslösen.

Eine Änderung: Verlagere diesen Build auf einen gemeinsamen Server oder einen einfachen CI-Dienst. Es muss nicht ausgefallen sein. Ein einzelnes Skript, das den Code holt, den Build ausführt und Erfolg oder Misserfolg meldet, ist bereits besser als ein Build auf einem Laptop. Jetzt kann jeder ihn auslösen. Jetzt ist das Ergebnis für alle sichtbar. Jetzt ist der Build wiederholbar.

Oder vielleicht ist das Problem ein anderes. Vielleicht ist der Build automatisiert, aber das Deployment ist immer noch eine manuelle Sequenz von SSH-Befehlen, die nur eine Person kennt. Eine Änderung: Schreibe diese Befehle in ein Skript, checke es in das Repository ein und führe es vom CI-System aus. Jetzt ist das Deployment dokumentiert, wiederholbar und nicht mehr vom Gedächtnis abhängig.

Oder vielleicht ist das Problem, dass die Staging-Umgebung nie der Produktion entspricht. Eine Änderung: Verwende das gleiche Deployment-Skript für beide Umgebungen. Wenn das Skript auf Staging funktioniert, aber in der Produktion fehlschlägt, wird der Unterschied zwischen den beiden Umgebungen sichtbar und behebbar.

Keine dieser Änderungen erfordert ein neues Plattform-Team. Keine erfordert den Kauf teurer Werkzeuge. Keine erfordert, dass sich alle auf einen vollständigen Workflow einigen. Sie erfordern nur, einen schmerzhaften Schritt auszuwählen und ihn ein bisschen besser zu machen.

Der Schneeballeffekt

Hier ist, was nach dieser ersten Änderung passiert: Du spürst sie. Das nächste Release ist ein bisschen weniger stressig. Der nächste Build erfordert keine Slack-Nachricht, die fragt, wer den richtigen Laptop hat. Das nächste Deployment erfordert keine Bildschirmfreigabe, damit jemand zusehen kann, wie die Befehle getippt werden.

Dieses Gefühl macht Lust, den nächsten Schritt zu verbessern. Und den nächsten. Nicht, weil es dir jemand gesagt hat, sondern weil du geschmeckt hast, wie es sich anfühlt, wenn ein Teil der Auslieferung vorhersagbar wird. Du willst mehr davon.

So geschieht echte CI/CD-Einführung. Nicht durch einen großen Plan. Nicht durch eine sechsmonatige Plattform-Migration. Durch eine Reihe kleiner, praktischer Verbesserungen, die sich im Laufe der Zeit summieren.

Ein schneller Weg, deinen ersten Schritt zu finden

Bevor du diesen Artikel schließt, mach Folgendes:

  1. Öffne dein Anwendungsrepository.
  2. Schreibe jeden Schritt vom Code-Commit bis zum Produktions-Deployment auf, so wie er heute tatsächlich abläuft.
  3. Markiere den Schritt, der am meisten wehtut – den, der am häufigsten fehlschlägt, am längsten dauert oder am meisten auf implizitem Wissen beruht.
  4. Entscheide dich für eine konkrete Sache, die du morgen tun kannst, um diesen Schritt ein bisschen besser zu machen. Nicht perfekt. Besser.

Das ist dein Startpunkt.

Was CI/CD wirklich ist

Nach all den Kapiteln, Diagrammen und Diskussionen über Pipelines, Plattformen und Governance ist dies die Kernwahrheit: Bei CI/CD geht es nicht um Werkzeuge. Es geht nicht darum, das perfekte Pipeline-Diagramm zu haben. Es geht nicht darum, das nachzumachen, was ein FAANG-Unternehmen tut.

CI/CD ist die Fähigkeit deiner Organisation, Änderungen – an Anwendungscode, Datenbankschemata und Infrastruktur – sicher auszuliefern und mit jeder Auslieferung besser darin zu werden.

Diese Fähigkeit kann man nicht kaufen. Man kann sie nicht installieren. Man kann sie nicht von einem Berater in einem zweiwöchigen Engagement konfigurieren lassen. Sie wird aufgebaut, eine kleine Änderung nach der anderen, von Menschen, die entscheiden, dass das heutige Release ein bisschen weniger schmerzhaft sein wird als das gestrige.

Fang morgen früh an. Wähle einen Schritt. Mach ihn besser. Und dann mach es wieder.