Angesichts der im letzten Artikel zum Thema angesprochenen Business-Vorteile mag Continuous Delivery wie eine Wunderwaffe erscheinen. Mit Magie hat das aber nichts zu tun, sondern lediglich mit einem Umdenken dahingehend, wie Software designed, entwickelt und ausgeliefert wird, gefolgt von einer fokussierten Investition in die Initiativen, die für die Implementierung erforderlich sind. In diesem ersten Schritt werden viele Unternehmen im Hinblick auf ihre CD-Transformation wankelmütig, also bei der Definition der und beim Commitment auf die Investition.

Da Continuous Delivery eine umfassende Überholung der technischen Prozesse, der operativen Kultur und des organisatorischen Denkens nötig macht, ist der Adaption eine nicht zu unterschätzende Anfangshürde in den Weg gestellt. Die Tatsache, dass viele Veränderungen erforderlich sind und dass Bereiche der Software-Delivery-Infrastruktur des Unternehmens ausgebaut werden müssen, die vielleicht jahrelang vernachlässigt wurden, kann durchaus eine bittere Pille sein. Bloß gut, dass Menschen unglaublich anpassungsfähig sind – vor allem, wenn uns als Lohn ein so mächtiger und vorteilhafter Software-Release-Prozess winkt.

Gut ist außerdem, dass die Transformation sämtlicher Aspekte des Business' im Hinblick auf die CD-Fähigkeit sich auch in anderer Hinsicht bezahlt macht. Selbst wenn im Unternehmen keine allumfassende CD-Transformation gelingt, so hat doch jede Teiltransformation große Vorteile.

Die große Anfangsinvestition ist eine Übereinkunft darüber, dass die Transition in Richtung CD ein würdiges, wichtiges Geschäftsziel ist. Und dieses Ziel ist nicht ohne die Beteiligung aller und auch nicht ohne einige ernstzunehmende (aber definitiv fruchtbare) Trade-offs im Rahmen dieser Transitionsperiode erreichbar.

"Lasst uns die nächsten paar Monate damit verbringen, am automatisierten Testing und der Build/Release-Infrastruktur zu arbeiten und den Prozess unserer Anwendungsentwicklung zu re-designen. Die Feature-Entwicklung können wir aufschieben." Kein Produktmanager würde so etwas jemals sagen. Seine Perspektive ist auch verständlich. Er trägt die Verantwortung dafür, in einem sich ständig wandelnden Markt zu reagieren. Er hat den Druck, die Konkurrenz ausmanövrieren zu müssen.

Eine Möglichkeit, Produktmanager und Business-Stakeholder an Bord zu holen, ist die, ihnen zu zeigen, wie viel schneller sie neue Features auf den Markt bringen können, wenn die Investition in CD beginnt, Früchte zu tragen – in einer Welt, in der Produktmanager ultra-leichtgewichtige Features ausliefern können, instrumentiert von Event-Analytics, und das bereits kurz nachdem die Idee aufgekommen ist. Die Analytics schicken Daten zurück, wie die User das Feature annehmen und wie sie es nutzen. Diese Informationen können dazu dienen, die Funktion weiter zu verfeinern. Ohne Continuous Delivery dauert so ein Prozess Monate. Mit CD können Iterationszyklen aus ein paar Tagen oder Wochen bestehen.

Das muss nicht bedeuten, dass die gesamte Feature-Entwicklung pausieren muss, bis der CD-Prozess läuft. Vielmehr müssen alle Geschäftsbereiche – Produktmanagement, Entwicklung, Entwicklungs-Support (QS, Ops, Build/Release) – an die langfristigen Vorteile glauben, die mit CD einhergehen. Wirkliche Disziplin ist dafür erforderlich, die Transition stets mit höchster Priorität zu behandeln, um sicherzustellen, dass die Initiative nicht stagniert oder sogar völlig im Sande verläuft.

Es gibt in jedem Unternehmen viele Bereiche, in denen investiert werden muss. Und während CD hier ein Beschleuniger sein kann, bringen diese Änderungen auch darüber hinaus Vorteile mit sich.

Automatisiertes Testing

Dies umfasst nicht nur den Fokus auf Unit-Tests, sondern auch auch Integrations- und Systemtests. Diese müssen mit einem System wie Bamboo auf automatisierte Weise abgebildet werden. Unabhängig davon, in welchem Stadium der CD-Adaption man sich befindet: Diese Tests werden helfen, Regressionen sofort zu identifizieren, und prompt zu kürzeren und stressärmeren Release-Zyklen führen.

Veränderungen der Anwendungsarchitektur

Die Orientierung zu einer Service-orientierten Architektur ist Pflicht. Wenn die Software nicht SaaS ist, muss man auf eine Komponentenarchitektur mit dem nötigen Versionierungs- und Release-Engineering für die Komponenten hinarbeiten, damit sie individuell ausgeliefert werden können. Sog. Feature Flagging und Canary Releases können diese komponentierten Services/Module dann nutzen. Es zahlt sich schon grundsätzlich aus, diese komplexen Systeme zu entkoppeln: Ihre Interfaces werden besser verstanden, was es Teams erlaubt, ihre Komponenten in eigenen Zyklen auszuliefern. Und es gibt CD-Fähigkeit oben drauf.

Build-/Test-Farm

Die Build-/Test-Farm benötigt ausreichende Kapazitäten, um Continuous Delivery zu unterstützen. Dadurch wird auch die Entwickler-Feedback-Schleife gestrafft und es wird einfacher, gegen unterschiedliche Betriebssysteme, Browser usw. zu testen. Die Anpassung der Kapazität der Test-Farm ist ein fortlaufender Prozess. Cloud-Anbieter wie Amazon Web Services können diesbezüglich viele Schmerzen vermeiden.

Schwerpunkt auf der Kultur

Continuous Delivery erfordert eine gewisse kulturelle Neuverkabelung, denn die Kernstruktur von CD ist eine Delivery-Pipeline, durch die Änderungen fließen, und keine Reihe aus von Menschen kontrollierten Toren, die passiert werden müssen. Die Natur dieser Struktur kann helfen, organisatorische Silos zu reduzieren. Darauf müssen die Leute, die sich in solchen Silos befinden, vorbereitet sein. Andernfalls kann es verständlicherweise passieren, dass sie dagegen ankämpfen und so die CD-Transition behindern.

Fokussierte Personalbesetzung

Damit die CD-Transformation Fahrt aufnimmt, kann es sinnvoll sein, zumindest temporär einen Fachmann einzustellen, dessen gesamter Fokus auf der infrastrukturellen Arbeit liegt. Das bringt auch frische Expertise ins Team und hilft dem Unternehmen, schneller voranzukommen.

Continuous Delivery erfordert Veränderung von Teams im gesamten Unternehmen. CD erfordert fokussierte Investitionen in Tools, Hardware und Leute. All das braucht Zeit, aber der Aufwand lohnt sich. Vor allem muss man sich darüber im Klaren sein, dass es nicht zielführend sein wird, die Transformation zu Continuous Delivery auf dem billigen Weg erreichen zu wollen – beispielsweise in der Slacktime oder mal eben in der Zeit zwischen Sprints und Releases. Stattdessen sollte man die Transition als Investition verstehen, die das Unternehmen in die Lage versetzen wird, in Echtzeit auf die dynamische Welt der Software-Industrie zu reagieren.

Kennen Sie Codeyard?

Das ist unsere neue Tool-Suite für Software-Entwicklungsteams, eine professionelle Lösung für das schnelle Aufsetzen einer passgenauen Infrastruktur als Grundlage für einen effektiven und effizienten Software-Entwicklungsprozesses – von der Idee bis zum auslieferbaren Produkt. Hier gibt es weitere Infos zu Codeyard.

Weiterführende Infos

Continuous Delivery in der Praxis: Deployment auf Knopfdruck und Release-Verwaltung mit Bamboo
Individuelle Software-Entwicklung: Workflows, Branching-Modelle und Continuous Delivery
Der Continuous-Delivery-Workflow für SaaS- und für installierte Software-Produkte
Der Continuous-Delivery-Workflow für Gitflow-Projekte