Kontinuierliche Lieferung 3.0: Der nächste 'nächste Schritt'

"Continuous Delivery ist die logische Weiterentwicklung von Agile" - diese Aussage stammt von Kurt Bittner aus dem Jahr 2013 in einem Bericht von Forrester. Damals war Continuous Delivery noch nicht so weit im Hype-Zyklus wie heute. Im Hype-Zyklus der Anwendungsentwicklung, den Gartner 2015 vorstellte, war Continuous Delivery auf dem Vormarsch und heute ist es in jedem Jahresplan eines IT-Unternehmens enthalten. Aber was genau ist Continuous Delivery und was fügt Continuous Delivery 3.0 diesem Konzept hinzu und was hat es mit der digitalen Disruption gemeinsam. In diesem Artikel finden Sie Antworten auf diese Fragen und erfahren, warum es wichtig ist, über den Hype-Zyklus hinauszuschauen.

Continuous Delivery ist die Einlösung des agilen Versprechens. Da über 95 % der Unternehmen Agile praktizieren, ist es für die meisten Unternehmen ein logischer und notwendiger Schritt, weiter zu gehen. Agile brachte uns den Vorteil, dass wir in der Lage waren, qualitativ hochwertige Software in wenigen Wochen zu produzieren. Aber die nächste Herausforderung, die Auslieferung der Software und die Bereitstellung des Geschäftswerts für die Kunden, erwies sich als eine ganz andere Sache.

An dieser Stelle kommt Continuous Delivery ins Spiel. Continuous Delivery ist ein Software-Engineering-Ansatz, bei dem Teams Software in kurzen Zyklen produzieren und sicherstellen, dass die Software jederzeit zuverlässig freigegeben werden kann. Das Ziel ist es, Software schneller und häufiger zu erstellen, zu testen und zu veröffentlichen. Im Idealfall bedeutet dies, dass alle Funktionen mit demselben wiederholbaren Prozess, der sogenannten Pipeline, geplant, realisiert und freigegeben werden. Quality Gates (wie Unit-Tests, kontinuierliche Builds, Akzeptanztests und Metriken) sorgen dafür, dass die Funktionalität und Qualität gewährleistet ist. Wenn etwas nicht in Ordnung ist, wird die Pipeline angehalten, damit der Fehler behoben werden kann. Daher sollten Metriken vorhanden sein, um den Fehler zu verstehen, zu verfolgen und zu lokalisieren, damit er nicht wieder auftritt. Jede Software, egal ob es sich um eine Fehlerbehebung, eine neue Funktion oder eine Änderungsanforderung handelt, wird auf die gleiche Weise behandelt. Das klingt perfekt für neue Projekte und neue Software, aber wie funktioniert das in bestehenden Szenarien und in Unternehmen, die bereits seit vielen Jahren Software entwickeln? Bevor ich darauf eingehe, möchte ich ein wenig über die digitale Disruption sprechen.

 Xebia DevOps