Zero-Day-Delivery: die nächste Stufe von DevOps?

Das Gefühl, eine gute Idee zu haben, ist kaum zu übertreffen. Doch für viele Unternehmen beginnt danach der schwierige Teil. Wie wäre es, wenn ihr die Umsetzung eurer Idee noch am selben Tag erleben könntet, an dem sie entstanden ist?

Meiner Meinung nach ist das die nächste Stufe von DevOps: Zero-Day Delivery.

Zero-Day Delivery grenzt an Continuous Delivery

Continuous Delivery erstellt Software in kurzen Zyklen. Das erhöht Geschwindigkeit und Frequenz und reduziert Fehler. Continuous Delivery bedeutet, dass ihr euren Code deployen und zur Nutzung bereitstellen könnt. Doch der letzte Schritt – dass Kunden die Änderungen an eurem Produkt tatsächlich erleben – erfolgt manuell. Wenn auch diese letzte Phase automatisiert ist, spricht man von Continuous Deployment.

Continuous Delivery ist ein wichtiger Schritt weg von traditionellen Methoden, die auf organisatorischen Silos beruhen. Doch die meisten Vorreiter bei Continuous Delivery schöpfen das Potenzial noch nicht weit genug aus. Beim Übergang von der Geschäftsidee zum Design, vom Design zur Entwicklung oder vom fertigen Feature zum veröffentlichten Produkt arbeiten sie weiterhin nach traditionellen Methoden.

Wenn die Organisation sich selbst im Weg steht

Continuous Delivery setzt eine bestimmte Unternehmenskultur und bestimmte Praktiken voraus, damit kontinuierlich ausgeliefert werden kann. Dennoch können organisatorische Silos dazu führen, dass die Auslieferung nicht sofort starten kann, sondern zunächst mehrere Schritte durchlaufen muss.

Unternehmen, die auf ihrer DevOps-Reise bereits weit fortgeschritten sind – und dabei häufig auch organisatorische Veränderungen durchlaufen –, können den gesamten Prozess beschleunigen: von der Idee bis zum Release eures Updates.

Doch statt dieses Potenzial zu nutzen, starten viele nur langsam: Sie setzen Continuous Delivery nur auf der Hälfte des Weges von der Idee zum Produkt ein – entweder während der Entwicklung oder in der Produktionsumgebung, aber nicht durchgängig.

Continuous Delivery muss sich frei entfalten können, um sein volles Potenzial auszuschöpfen. Dieses Potenzial nenne ich Zero-Day Delivery.

Zero-Day Delivery basiert auf DevOps im großen Ganzen

Stellt euch Folgendes vor: Wenn ihr ein Softwareprojekt startet – oder noch besser, wenn ihr beschließt, ein Softwareprojekt zu starten, oder darüber nachdenkt –, könnte es noch am selben Tag in der Produktionsumgebung laufen.

Anders als eure Idee ist das keine bloße Vorstellung. Es ist eine Continuous-Delivery-Pipeline – oder besser noch eine Continuous-Deployment-Pipeline – aus Tools und Projektvorlagen, darunter zum Beispiel:

• Anbindungen an Anforderungsmanagement und Versionskontrolle

• ein Designsystem und seine UI-Komponenten

• automatisierte Testvorlagen und Infrastrukturen

• Release-Automatisierung.

Ihr könnt eure Idee in die Pipeline geben, und auf der anderen Seite kommt Software heraus. Nur 10–20 % des Codes machen das eigentliche Produkt aus. Der Rest besteht aus gemeinsam genutzten Komponenten, Vorlagen und Praktiken, die DevOps optimal unterstützen.

Die Projektvorlagen sind der Ausgangspunkt für eine neue Idee. Sie sind mit der Toolchain verbunden. Sobald ihr diesen ersten Teil des Codes klont – selbst wenn er nur 10–20 % der ursprünglichen Vorlage ausmacht –, wartet in dieser Vorlage bereits ein Schlüssel zur Produktionsumgebung auf euch.

Die Vorteile von Zero-Day Delivery sind enorm

1. Zero-Day Delivery liefert euch sofortiges Feedback zu eurer Idee – und das ist unbezahlbar. Ihr müsst nicht mehr Wochen warten, um zu erfahren, wie sich euer neues Feature verhält oder ob es euren Nutzern gefällt. Keine Demos mehr: Ihr seht eure Idee direkt in der Produktionsumgebung.

2. Zero-Day Delivery verändert, wie ihr die ersten Schritte einer neuen Idee, eines neuen Features oder einer Änderung an eurer Software wahrnehmt. Ihr startet nicht mit Warten, sondern mit Auslieferung. Auch aus Teamsicht ist es ganz einfach: Die Pipeline steht bereits, und diese Arbeit wurde skalierbar umgesetzt. Ihr könnt sie auch an andere Teams in der Organisation weitergeben.

3. Zero-Day Delivery verkürzt eure Time-to-Market um Wochen. Entscheidend ist nicht, wann ihr erfahrt, dass etwas nicht stimmt oder etwas passiert. Entscheidend ist, wann euer Unternehmen darauf reagiert.

4. Zero-Day Delivery fördert auch das schnelle Scheitern. Ihr könnt schlechte Ideen sofort als das entlarven, was sie sind – etwas, das euch in der Konzeptphase vielleicht nicht auffällt.

Liefert nicht aus, was fertig ist – liefert aus, was funktioniert

Zero-Day-Delivery bedeutet den Wandel: weg von der Auslieferung dessen, was fertig ist, hin zur Auslieferung dessen, was funktioniert.

Damit verpflichtet ihr euch zu möglichst kleinen Auslieferungen – und macht in der Praxis kleinere Fehler. Außerdem ermöglicht es Canary Testing: Neue Features werden zunächst nur für ausgewählte Kunden bereitgestellt. Die gewonnenen Erkenntnisse helfen dabei, das Feature fertigzustellen oder weiterzuentwickeln.

Und Auslieferung ist nicht dasselbe wie Release

Nur weil ihr etwas in eine Produktions- oder produktionsähnliche Umgebung überführt, müsst ihr es nicht noch am selben Tag für eure Kunden veröffentlichen. Endanwender müssen es erst sehen, wenn ihr den Schalter umlegt und es aktiviert.

Der entscheidende Paradigmenwechsel besteht darin, dass Zero-Day-Delivery nicht bedeutet, nur fertige Features zu veröffentlichen, sondern funktionierende Software auszuliefern. Im Vergleich zum Zusammenführen und Veröffentlichen ausschließlich „fertiger“ Features löst das viele Probleme bei Integration und Testautomatisierung. Außerdem könnt ihr ein neues Feature mit Pilotkunden in der Produktion testen, bevor ihr es für alle veröffentlicht.

Zero-Day-Delivery ist kein Sprung ins Ungewisse. Es ist DevOps.

Dass Auslieferung nicht dasselbe wie Release ist, sollte viele Bedenken ausräumen. Doch ich möchte vor allem betonen: Unternehmen haben nichts zu verlieren. Die Technologie ist vorhanden, um Zero-Day-Delivery Wirklichkeit werden zu lassen, und wir haben es in der Praxis erlebt.

Wir leben bereits in einer Welt, in der Delivery-Zyklen so schnell sind, dass sie am selben Tag stattfinden, an dem eine Idee entsteht. Es geht nicht um den Wettbewerbsvorteil, den ihr durch diese Praktiken gewinnt, sondern um die Opportunitätskosten, wenn ihr sie nicht nutzt.

Ihr entwickelt nicht länger ein Jahr lang eine Uhr. Ihr schafft kontinuierlich wachsenden Mehrwert für eure Kunden und reagiert auf ein komplexes Umfeld, indem ihr in eurem Unternehmen Bedingungen schafft, unter denen neue Ideen schnell umgesetzt werden.