Von einer Welt, in der Software-Entwickler, Betrieb und InfoSec Freunde sind

Im Blog Software-Entwicklung im digitalen Großraumbüro habe ich das Konzept von “Continuous Integration” besprochen. Einfach zu erklären, aber schwierig umzusetzen. Vieles davon fühlt sich an wie ein Bungee-Sprung. Die Logik sagt ja, die Emotionen schreien “Bloß nicht!”

Wenn Ihr Nervenkostüm das verkraftet hat, dann möchte ich in diesem Blog noch zwei Schritte weitergehen:

Tata!

Auftritt “Continuous Delivery / Deployment”

“Continuous Integration” führt wie beschrieben dazu, dass alle Entwickler gezwungenermassen in einem Boot sitzen. Mit “Continuous Deploypment / Delivery” weitet man dieses Verständnis nun auch auf die Rollen von Qualitätssicherung, Betrieb und Security aus. Jetzt wird es richtig wüst. Es ist schon ein Himmelfahrtskommando, mehrere Entwickler aneinander zu binden. Aber wie soll das jetzt auch noch rollen-übergreifend funktionieren?

Aber schauen wir uns das mal vom theoretischen Konzept an!

Während Continuous Integration “nur” das permanente erfolgreiche Integrieren der individuellen Änderungen der Projektmitarbeiter propagiert, geht Continous Deployment bzw. Delivery noch einen Schritt weiter. Die zusammengeführten Änderungen (“Continuous Integration”) müssen in einer produktionsnahen Umgebung lauffähig sein (“Continuous Delivery”) oder sogar in die tatsächliche Produktions-Umgebung (“Continuous Deployment”) übertragen werden.

Also ganz anschaulich: Der siebzehnte Entwickler von links fügt eine Code-Zeile dazu und das ganze soll automatisch in die Produktion übertragen werden und damit sofort auf Anwender bzw. Kunden losgelassen werden – ohne einem Change Control Board, ohne Qualitätssicherung, ohne dem formalen “grünen Licht” von wem auch immer? Also ein Drahtseilakt ohne Fallnetz?

Willkommen in der Welt von DevOps, Continuous Deployment und Micro-Services Architekturen.

Wenn man sich das in der Realität vorstellt, klingt es so, als würden damit Qualitätssicherung und Security elegant ausgeknockt! Setzt man also einfach auf das Prinzip Hoffnung oder auf besonders tolerante Kunden/Anwender, die bei Software sowieso damit rechnen, dass sie nicht vernünftig funktioniert?

Wenn man alles so beibehält wie vorher, dann bleibt bei einer Umstellung auf Continuous Deployment tatsächlich nur hoffen und beten. Das IST dann ein Drahtseilakt ohne Fallnetz.

Aber es gibt dazu verblüffende Zahlen:

Firmen, die mit dieser Umstellung Erfolg haben, berichten, dass die Software tatsächlich stabiler wurde.¹ Und noch überraschender: Die Autoren des DevOps-Report hat sogar empirisch bewiesen, dass die Häufigkeit von Deployments und die Stabilität nicht entgegen gesetzt sind, sondern sich verstärken.² Also statt “Never change a running system”, “Change it as often as possible to make it stable!”

Wie ist das möglich? 

Wenn über Continuous Deployment gesprochen wird, geht es zumeist um die Verkürzung der Zeit, in der neue Funktionalität für Anwender / Kunden live gestellt werden kann (“Time to market”).  Vorbei die Zeiten, wo neue Funktionalitäten ein bis zwei Mal im Jahr mit einem Big bang live gingen. Die Software entwickelt sich sozusagen in einem permanenten Fluss – keine radikalen Änderungen, sondern “Continuous”. 

Das ist ein klarer Wettbewerbsvorteil! 

Aber mindestens ebenso wichtig ist das nahezu unmittelbare Feedback für alle, die Änderungen herbei führen. Das sind natürlich klassischerweise Software-Entwickler, aber ebenso Betriebsmitarbeiter, die an der Infrastruktur Änderungen durchführen, Tester, die neue Test-Verfahren einführen und Security-Verantwortliche, die neue Policies scharf schalten. Nur durch unmittelbares und direkt zur Änderung zuordenbares Feedback wird ermöglicht, die Ursache von einem auftretenden Problem rasch zu identifizieren und zu beheben. Wenn hingegen alle 6 Monate auf einen Schlag Tausende von Änderungen aktiviert werden:

• kann man sich meistens nur mehr dunkel erinnern, welche Änderung man, warum durchgeführt hat
• wird jeder (zurecht oder zu unrecht) vermuten, dass seine/ihre Änderung das Problem nicht hervorgerufen hat

Das klingt logisch! 

Aber wie kann das unter Einbeziehung von Qualitätsanforderungen, Security und Compliance funktionieren? Damit landen wir direkt beim geistigen Bruder von Continuous Deployment: DevSecOps. 

Es geht um ein komplettes Neudenken des gesamten Entwicklungs- und Deployment-Prozess mit einer gesamtheitlichen Sichtweise. Das heißt, nicht ein isoliertes Optimieren von Entwicklung oder ein isoliertes Optimieren von Betrieb oder ein isoliertes Optimieren von Security. Es geht um das Optimieren des Gesamten.

Schöne Worte! Aber wie lässt sich das bewerkstelligen?

• Automatisierte, umfangreiche Tests: Bei der großen Menge von Deployments würde jede manuell erforderliche Test-Prozedur das System ad absurdum führen.

• Automatisches Roll-back: Es muss bei Problemen möglich sein, auf Knopfdruck voll-automatisch auf die vorherige Version zurücksteigen zu können. Das bedeutet als Folge auch Infrastrukturen, die auf Knopfdruck zurückgesetzt werden können, was aus praktischer Sicht fast nur mit “Infrastructure as Code” und “immutability” (Unveränderlichkeit) erreicht werden kann.

• Eine enge Zusammenarbeit von Dev und Ops – über den gesamten Lebenszyklus. Dev muss verstehen, was eine bestimmte Änderung für die Produktionsumgebung (Ops) bedeutet. Ops muss die Infrastruktur so bereit stellen, dass Dev effizient und sicher damit arbeiten kann.

• Das Thema Sicherheit muss in den gesamten Prozess mit eingebunden sein. Dh. nicht erst beim Deployment oder – noch schlimmer – bei Security-Vorfällen, sondern schon bei Analyse, Design und auch Entwicklung. Frei nach dem Motto für alle: “Wir sind Security!”

Ein sehr anschauliches Beispiel für die mögliche Umsetzung dieser Prinzipien liefert das “DevOps Audit Defense Toolkit”. Statt sich vor den drohenden Fragen bei einem Audit zu Tode zu fürchten, wird vorgeschlagen, die Konzepte und Umsetzung von DevSecOps und Continuous Deployment zu erklären. Intensive Diskussionen sind mit Sicherheit zu erwarten, aber die Erfahrungsberichte von erfolgreichen Umsetzungen sprechen eine klare Sprache. 

Zusammenfassend kann man sagen: 

Zu “Continuous Deployment” gehört viel Mut, Neugierde und das vielleicht wichtigste: Eine Portion Verzweiflung, weil es mit den bestehenden Prozessen einfach nicht funktioniert! Es gibt viel Material und viele Beispiele, dass es sich dabei nicht um eine theoretische Phantasie handelt. Deswegen ist mein Rat, es einfach mal auszuprobieren. Nicht im kritischsten Projekt, nicht mit den größten Skeptikern. Sondern mit einem Team, dem man zutraut, in einem Kollektiv zu denken. Und dann beobachten, was passiert!

Fussnoten

¹ Gruver, Gary, and Tommy Mouser. Leading the Transformation: Applying Agile and Devops Principles at Scale. Illustrated Edition. Portland, OR: It Revolution Press, 2015.

² Webteam, Puppet. “2020 State of DevOps Report | Presented by Puppet, & CircleCi.” Accessed May 8, 2021. https://puppet.com/resources/report/2020-state-of-devops-report/.