Foto von Duc Van auf Unsplash
Geschwindigkeit war nie der schwierige Teil bei CI/CD
M. Zakyuddin Munziri
@zakiego
Ursprünglich auf English geschrieben.
Lange Zeit glaubten Teams, dass schnelleres CI/CD die meisten Delivery-Probleme lösen würde.
Pipelines fühlten sich langsam an. Builds dauerten zu lange. Deploys stauten sich. Also optimierten wir die Geschwindigkeit.
Wir parallelisierten Jobs. Fügten Caching hinzu. Auto-Deploy bei Merge.
CI/CD wurde schnell.
Das Ausliefern (Shipping) fühlte sich immer noch beängstigend an.
Das war der Moment, in dem es klar wurde. Geschwindigkeit war nie der schwierige Teil.
Schnellere Pipelines entfernten das Zögern nicht
Selbst mit schnellen Pipelines hielten Ingenieure vor dem Ausliefern immer noch inne.
Rollbacks fühlten sich riskant an. Vorfälle verursachten immer noch Stress. Deploy-Buttons wurden vorsichtig geklickt.
Nichts blockierte technisch das Release. Was es blockierte, war Zweifel.
Schnelles CI/CD bedeutet nur, dass Code sich schnell durch ein System bewegt. Es bedeutet nicht, dass das System sicher zu ändern ist.
CI/CD-Geschwindigkeit löst Ausführung, nicht Vertrauen
CI/CD ist großartig in der Ausführung.
Es baut, testet, paketiert und deployt zuverlässig und wiederholbar. Die meisten Teams können dieses Level mit genug Aufwand erreichen.
Vertrauen (Confidence) ist anders.
Vertrauen ist zu wissen, was passiert, wenn etwas schiefgeht.
Wie groß die Auswirkung ist. Wie schnell das System es dir sagt. Wie schnell du es stoppen kannst.
Geschwindigkeit allein beantwortet nichts davon.
Grüne Haken schaffen kein Vertrauen
Das ist eine häufige Falle.
Alle Checks sind grün. Tests bestehen. Pipelines sind erfolgreich.
Trotzdem fühlt sich niemand gut beim Ausliefern.
Grüne Haken sagen dir, dass Regeln bestanden wurden. Sie sagen dir nicht, wie sich das System unter realen Bedingungen verhält.
Vertrauen wird nicht durch das Bestehen von Checks aufgebaut. Es wird aufgebaut, indem man sieht, wie Ausfälle eingedämmt und behoben werden.
Was das Ausliefern tatsächlich sicher anfühlte
Die Dinge änderten sich, als wir aufhörten zu fragen, wie wir CI/CD schneller machen können, und anfingen zu fragen, wie wir das Ausliefern sicherer machen können.
Ein paar Dinge waren wichtiger als rohe Geschwindigkeit.
Rollback-Pfade, die geübt wurden, nicht nur dokumentiert.
Feature Flags, die als Sicherheitsschalter genutzt wurden, nicht nur als Launch-Tools.
Preview-Umgebungen, die Änderungen früh sichtbar machten.
Feedback-Schleifen, die Probleme aufzeigten, bevor Nutzer sich beschwerten.
Nichts davon war komplex. Alles davon reduzierte Unsicherheit.
Vertrauen ist eine Systemeigenschaft
Das war der größte Mindset-Shift.
Vertrauen lebt nicht in einem Tool oder einer Pipeline.
Wenn Rollback langsam ist, ist das Vertrauen niedrig. Wenn Alarme laut sind, ist das Vertrauen niedrig. Wenn Eigentum unklar ist, ist das Vertrauen niedrig.
Automatisierung verstärkt das System, das du bereits hast. Wenn das System fragil ist, lässt schnelleres CI/CD das Scheitern nur früher ankommen.
Was sich nicht geändert hat
Ingenieure treffen immer noch Entscheidungen.
Urteilsvermögen ist immer noch wichtig. Trade-offs existieren immer noch. Edge Cases passieren immer noch.
CI/CD hilft, Code zu bewegen. Es entfernt nicht die Verantwortung.
Vertrauen kommt daher, zu wissen, dass das System dir helfen wird, dich zu erholen, anstatt dich zu bestrafen.
Schlusswort
Geschwindigkeit in CI/CD ist Grundvoraussetzung (table stakes).
Die wirkliche Arbeit ist der Bau von Systemen, die sich vorhersehbar verhalten, wenn Dinge schiefgehen.
Wenn du nur für Geschwindigkeit optimierst, liefern Teams vielleicht schneller aus, fühlen sich aber schlechter.
Wenn du für Vertrauen optimierst, folgt Geschwindigkeit natürlich.
Geschwindigkeit war nie der schwierige Teil.
