Continuous Delivery – Keine Frage der Technik und kein Trend aus dem Silicon Valley

Wer sich mit agiler Softwareentwicklung beschäftigt, der kommt um das Thema Continuous Delivery nicht herum. Es fing mit Continuous Integration an, was soviel bedeutet wie dass ein Entwickler Programmcode verändert und diese Softwarestand in das zentrale Codeverwaltungssystem hochlädt. Dieser Code wird dann von einer Software automatisch kompiliert und anschließend werden noch die Testfälle ausgeführt. Das erhöht schon mal die Codequalität, denn wenn Änderungen durchgeführt wurden, die dazu führen, dass der gesamte Softwarestand nicht mehr kompiliert oder die Testfälle nicht mehr erfolgreich ausgeführt werden, weiß man sofort Bescheid, dass es ein Problem gibt und kann es beheben.

Seit einiger Zeit spricht man aber von Continuous Delivery, das noch einen Schritt weiter geht. Sobald die Kompilierung durchgeführt wurde und alle Testfälle erfolgreich abgeschlossen wurden, wird der neue Softwarestand sofort dem Kunden zur Verfügung gestellt und er kann sofort den neuesten Softwarestand verwenden. Einmal konfiguriert geschieht dies dann auf Knopfdruck, was den Aufwand für das Deployment erheblich reduziert.

Der Prozess im Hintergrund

Nun ist es bei wichtigen Softwaresystemen so, dass ein sogenanntes Staging durchgeführt wird. Ist ein Entwickler fertig und wurde der Code von anderen Entwicklern geprüft, wird der Softwarestand auf ein Testsystem gespielt. Dort werden dann in der Regel manuelle Tests von den Testabteilungen durchgeführt. Waren diese Tests erfolgreich wird der Softwarestand auf eine Systemintegrationsumgebung gespielt. Diese Systemumgebung ist im Idealfall eine Kopie der echten produktiven Umgebung. Dort sollten Integrationstests, Last- und Performancetests sowie Penetrationtests (Sicherheitstests) durchgeführt werden. Ist hier die Freigabe erteilt worden, so kann die Software dann auf die Produktionsserver übernommen werden.

Dieser Prozess hört sich aufwendig an und das ist er auch. Aber für Softwaresysteme, deren Ausfall hohe Kosten verursacht, ist dieser Weg der absolut richtige. Das Problem ist nur, dass es in den Unternehmen keine Unterscheidung zwischen Applikationen gibt, bei denen es kein Problem ist wenn sie mal nicht laufen und hochverfügbaren Applikationen, die immer laufen müssen. Es gilt überall der gleiche Prozess.

Continuous Delivery – Ein Trend aus dem Silicon Valley? Keineswegs!

Nun, was hat das mit Continuous Delivery zu tun. Ich höre immer wieder, dass Vorstände von Unternehmen ins Silicon Valley fahren und sich dort die achso tollen Technologien zeigen lassen, wie dort Continuous Delivery gelebt wird. Die Vorstände lassen sich teure Plattformen aufschwätzen, weil sie dann in der Lage sind, entwickelte Software sofort in die Produktion zu schicken und dass alles auf Knopfdruck passiert.

Softwaresysteme, die Continuous Delivery unterstützen, gibt es aber mittlerweile seit einigen Jahren. Sie gibt es sogar als OpenSource kostenlos und richtig gut wie zum Beispiel das Softwaresystem Jenkins. Für einige unserer Kunden haben wir Continuous Delivery Systeme im Einsatz und können jederzeit automatisch oder auf Knopfdruck Softwarestände auf Servern austauschen und der Anwender bekommt nichts davon mit.

Nun, was machen unsere Vorstände die teure Technologie und Beratug zur Umsetzung eingekauft haben? Sie fahren nach Hause berichten in Ihren Firmen von diesen tollen Werkzeugen und versprechen sich davon, dass ihre Softwaresysteme ab morgen viel schneller mit neuen Features versorgt werden. Nach einem halben Jahr stellen sie fest, dass die neuen Systeme integriert wurden und großartig funktionieren, aber es hat sich nichts geändert! Die Time to Market ist gleich geblieben! Die Ursache liegt wie so oft nicht in der Technik, sondern in der Organisation. Denn an die Prozesse haben sie nicht gedacht. Sie haben nicht daran gedacht, dass in Ihren Prozessen umfangreiche Tests vorgeschrieben sind, die einfach ihre Zeit dauern und natürlich auch ihre Berechtigung haben. Da auch nicht die Kritikalität einer Applikation bewertet wird, weil es ja viel einfacher ist einen einzigen Prozess für alle Applikationen zu haben, schaffen Sie es nicht einmal bei den weniger kritischen Lösungen den Weg vom Entwicklerrechner bis hin zum Produktionsserver zu verkürzen.

Time to Market: Auch andere Stellschrauben drehen

Und plötzlich ist die Angst da: Wie, wir haben soviel investiert und sind trotzdem nicht schneller? Wir haben so eine wahnsinnig tolle Technologie frisch aus dem Silicon Valley importiert und hängen im Zeitplan hinterher? Auf einmal scheint sich die neue Investition nicht mehr auszuzahlen. Selbstverständlich ein Irrglaube, denn wie wir nun ja wissen, hängt es eher am Prozess. Und gute Software braucht einfach einen guten Prozess. Und wenn dieser erst einmal auf die Art der Applikation (Hochverfügbar? Kritisch? Oder internes Tool, an dem nicht der Unternehmenserfolg hängt?) zugeschnitten ist, was durchaus eine Weile brauchen kann, werden erste Erfolge spürbar.

Doch können wir an dieser Stelle alls CEOs, CDOs, CIOs und sonstige Vorstände beruhigen: Sie haben einen sehr wichtigen Schritt gemacht mit der Einführung von Continuous Delivery, auch wenn Sie danach eventuell noch mal Ihre Prozesse angreifen müssen und das wieder mal einen Mehraufwand darstellt – aber denken Sie doch mal darüber nach, ob nicht andere Stellschrauben anders justiert werden können, damit Ihre Unternehmens-Maschinerie besser läuft … vor allem hinsichtlich Time to Market, denn da gibt es nicht nur Continuous Delivery, um eine Softwareauslieferung zu beschleunigen.

Ein Ansatz, der die Entwicklungszeit und vor allem Testzeiträume stark verkürzt und die Qualität einer Software erheblich verbessert, ist das Model Driven Development. Hier wird das Datenmodell, das der Software zugrund liegt, an einer Stelle konzipiert und hinterlegt. Und der Großteil der Applikationslogik wird automatisiert erstellt. Inklusive automatisierter Tests. Ohne jegliches Zutun. Ohne extra Aufwand. Und dem Time to Market können Sie ganz entspannt entgegen blicken.

Was also lernen wir daraus?

1. Um Continuous Delivery Systeme zu etablieren muss man nicht nach Kalifornien fliegen
2. Die Technik hilft alleine gar nichts. Es sind die Prozesse, die geändert werden müssen
3. Es gibt andere Stellschrauben, mit denen man die Time to Market Zeit erheblich mehr verbessern kann