Sind es nicht faszinierende Zeiten, in denen ein einzelnes Feature Milliarden an Börsenwert produzieren oder über Nacht vernichten kann? Den Trend, in dem wir uns aktuell bewegen, wurde in einem Vortrag im Rahmen des “Architecture Gathering 2018” unlängst beschrieben: Wir befinden uns in der post-industriellen Ära der hochdynamischen, globalen Märkte und disruptiven Veränderungen. Im Fokus stehen dabei weniger die Entwicklungskosten. Time-to-Market ist der entscheidende Erfolgsfaktor. Wer zuerst kommt und den nächsten Hype inszeniert, hat die besten Chancen auf das große Geschäft.

In der Softwareentwicklung ist Geschwindigkeit längst keine Hexerei mehr. Immer höhere Automatisierungsgrade und ein verändertes Prozessdesign ermöglichen Performancesprünge, die noch vor wenigen Jahren undenkbar schienen. Der Softwarearchitekt ist dabei der zentrale „Driver“, sozusagen der Speedmaster im Projekt. Mit seinem Architekturkonzept steuert er nahezu alle relevanten Parameter, um ein Projekt auf seine Anforderungen auszurichten. Wenn Time-to-Market die Priorität hat, sind flexible Architekturmodelle und Continuous Delivery zumeist die erste Wahl. Erstere schaffen mit weitgehend autarken Komponenten bis hin zu Microservices die Voraussetzungen, um effizient zu entwickeln und über die Continuous Delivery Pipeline fortlaufend zu liefern. Aber schauen wir uns das einmal genauer an.

Ein erster Blick auf Continuous Delivery

Continuous Delivery – kurz „CD“ genannt – beschreibt eine Sammlung von Techniken, Prozessen und Werkzeugen, mit deren Hilfe kurze Entwicklungszyklen und die schnelle Auslieferung von Software-Updates oder produktiven Endsystemen ermöglicht werden. CD zielt darauf ab, jede Entwicklung oder Änderung im Code sofort in eine mehrstufige, weitgehend automatisierte Test-Pipeline zu übergeben und nach erfolgreichem Durchlauf mit dem nächsten Deployment produktiv zu stellen. Typischerweise werden bei den Tests drei Phasen unterschieden: Eine Commit Stage, auf der die Software gebaut und die Unit-Tests durchgeführt werden, eine Accaptance Test Stage für die Integrations-, Akzeptanz- und Systemtests sowie eine dritte Phase, in der gegebenenfalls manuelle Tests und ein Freigabeprozess stattfinden können. Für jede Phase gilt das Prinzip „Stop-the-line“: Bei Ermittlung eines Fehlers wird die Test-Pipeline angehalten, bis das Problem behoben ist. Der Entwickler erhält umgehend Feedback. So können Fehler frühzeitig entdeckt und beseitigt werden.

Continuous Delivery und DevOps

In der Konsequenz durchläuft jeder Softwarestand zigmal die Test-Pipeline und muss entsprechend zigmal auf einer Testumgebung installiert werden. Traditionell liegt die Installation für den Test im Aufgabenbereich des Betriebs. Wie soll sich das in der Praxis darstellen lassen? Betrieb und Entwicklung müssen die Konfiguration der Anwendung und die Deployments in so enger Abstimmung planen, dass eine Trennung der Abteilungen nicht länger gegeben ist. DevOps, die Zusammenlegung von Development und Operations, ist tatsächlich eine notwendige Konsequenz, wenn die Umsetzung von Continuous Delivery zum Erfolg führen soll.

Der Softwarearchitekt im Lead

Wenn wir die angesprochenen Themen zusammennehmen, ist der Softwarearchitekt der einzige im Bunde, der gleichzeitig über die Kompetenz verfügt und frei ist von Interessenskonflikten. Allein deshalb bringt es viele Vorteile, Design und Überwachung von Continuous Delivery Projekten im Aufgabenbereich erfahrener Architekten anzusiedeln. Wir haben gesehen, dass die Konzeption von Continuous Delivery unmittelbar abhängig vom Architekturmodell ist. Der Architekt kann Continuous Delivery also im Flow des Gesamtkonzepts entwickeln – auch das ist ein Argument. Weiterhin ist die Perspektive des Architekten auf die Test-Szenarien naturgemäß weniger Tool-getrieben und er kann aufkommende Konflikte von Entwicklung und Betrieb aus dem Konzept heraus moderieren.

Ein Aufwand, der sich lohnen sollte

Mit Continuous Delivery erweitern Softwarearchitekten ihren Kompetenzbereich um ein Thema, mit dem sie punkten können: Speed! Der Entwickler profitiert von unmittelbarem Feedback aus der Test-Pipeline, von der Verringerung des Risikos in der Entwicklung und einer drastischen Verkürzung der Zeit bis zur Produktivstellung. Neue Features können innerhalb weniger Tage zum Anwender gebracht und bei Bedarf mit Varianten ausgetestet werden. So lassen sich auch höchste Anforderungen an die Time-to-Market erfüllen.

Die wichtigsten Grundlagen und Tools rund um Continuous Delivery sind Teil unseres Trainings „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ auf iSAQB Advanced-Level. Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Nächstes Training: 05.-07. März 2019 in Ludwigshafen
Weitere Infos: www.itech-progress.com/isaqb-improve/

 


1 Quelle: Uwe Friedrichsen, „Life after Microservices“, zum Artikel auf Slideshare hier klicken