Freigabe, Software Deployment und die CI/CD‑Pipeline

An unserer Hochschule gibt es jedes Semester einen mitternächtlichen Termin, bis zum dem seitens der Studierenden online‑Prüfungsleistungen hochzuladen sind. Wann, glauben Sie, geht es so richtig los? Genau: um 23:55h. Zwei mal im Jahr sind Server und Übertragungskanäle maximal gefordert, sonst langweilen sie sich. Black Friday, DoS‑Attacken, Bugs in der Software, eine Akkumulation fehlschlagener Cronjobs und Meldungen in Medien sowie unerwartet viral gehende Hypes (Stichwort: „The‑Reddit‑Effect“) können im Betrieb steile Lastspitzen mit hoher Amplitude erzeugen. Wer ein System freigibt, steht mit seinem Namen dafür ein, dass es den Anforderungen der Welt gewachsen sein wird. Ein mit z.B. der CIT‑Szenario‑Technik moderiertes Seminar erzeugt zusätzliche Sicherheit und kann später als Nachweis umgesetzter Due Diligence (angemessene Sorgfalt) dienen. Aber irgendwann...

...lässt es sich nicht mehr vermeiden: das Projekt könnte jetzt abgeschlossen, das Ergebnis in den Realbetrieb überführt werden (Deployment). Irgend jemand hat mit Unterschrift dafür gerade zu stehen, dass alles Menschenmögliche unternommen wurde, um Funktionalität, funktionale Sicherheit, Zertifizierungen, Cybersecurity, in geltendes Recht überführte Normen, staatl. Fördermöglichkeiten, Kundenerfordernisse (was mehr ist als die kundenseitigen Spezifikationen), gesetzliche Rahmenbedingungen und Unabsehbares der Zukunft gut zu bewältigen. Zugleich wissen wir, dass es keine fehlerfreie Software respektablen Umfangs gibt. Wer weiß schon, wie viel digitales Klebeband, coole Sonderlocken und krude Workarounds die Entwicklerschaft der Einfachheit auf dem kleinen Dienstweg oder zur Vermeidung von Wartezeiten und zum Weckducken vor Konflikten halber eingehäkelt hat? (Wobei es wahrscheinlich ist, dass die Konfliktauslöser tief ins soziotechnischen System „Firma“ eingestrickt sind, wofür die Entwicklerschaft nun wirklich nichts kann) Oder wie hochwertig die Staging‑Umgebung für die Tests die tatsächlichen Betriebsumstände simuliert? Wie kreativ, umfassend, reliabel und automatisiert das Testteam die Tests gestaltet hat? Ob fahrlässigerweise lediglich der aktive Code oder wirklich die gesamte Software im Testprozess steht? Wie gut der inzwischen entstandene Entropie‑Zoo an Tools tatsächlich lückenlos ohne Schlupfmöglichkeit für Malware und Human Hacking harmoniert? Welche Änderungen externer Abhängigkeiten während der Betriebsphase unerwartet über uns hereinbrechen und wie gut die Entwicklerschaft dies in ihrer Glaskugel antizipieren konnte? Insbesondere bei der Auslieferung von Maschinen und anderen Produkten, die embedded Software enthalten und die Jahre oder Jahrzehnte in Betrieb sind, fällt die vorausschauende Absicherung des Betriebs schwer.

„Freitagnachmittag ist die beste Zeit für ein Deployment. Da hat man das ganze Wochenende zum Weinen.“
Szene‑Spruch

Frühe Hinweise auf Probleme sind Ticket‑Pingpong, Schuldzuweisungen zwischen den Teams, Fluktuation sowie einer verdächtigen Stille, wenn es um mögliche Schwächen des Systems geht. Feature‑Flags und Blue‑Green‑Deployments, Dependency‑Proxys, Shift‑Left und Canary‑Deployments sind erste Begriffe aus einer großen Fülle, die nützliche Abhilfestrategien kennzeichnet. Und nur allzu oft sind vulnerable Elemente vorhanden, die aus Security‑Sicht als höchst riskant einzustufen sind und zugleich als „unvermeidlich“ erklärt werden. Es existieren viele berechtigte Gründe für Schweißperlen auf der Stirn des Freigebenden. Das Fundament jeder Fehlervermeidung und eleganter Arbeitsleistung sind Menschen. Oder wie es bei TOYOTA sinngemäß heißt:

„Erst entwickeln wir Menschen. Und DIE entwickeln dann Autos.“
Zugeschrieben Fujio Cho, u.a. ehem. Chairman der Toyota Motor Corporation

Es gibt bereits am Anfang der Entwicklung kein Erkennungskriterium für einen vollständigen und korrekt formulierten Spezifikationssatz. Codiervorgaben werden niemals perfekt sein und es existiert meist auch keine Möglichkeit für sog. „vollständige Tests“. Je nach Rechtslage und Anwendungsfall kann es sich bei der Freigabe darüber hinaus um eine sog. „nicht delegierbare Aufgabe“ handeln - Die Mitglieder der Geschäftsleitung bleiben in der persönlichen Haftung. Schauen wir uns alleine die Rechtslage an, stoßen wir schnell auf eine Fülle einzuhaltender Judikate. Einige Beispiele in verkürzten Schlagworten:

• Rechtsetzung durch Gerichtsurteile
• CRA - Cyber Resilience Act
• AI Act
• Digital Omnibus
• E‑Evidence
• Data Act
• Cybercrime Convention des Europarates
• Data Governance Act
• Digital Markets Act
• Digital Services Act
• DSGVO
• Maschinenrichtlinie
• NIS_x Network and Information Security
• RED - Radio Equipment Directive
• IEC 61508 - Internationale Basisnorm für funktionale Sicherheit
• ISO 26262 - Funktionale Sicherheit nach IEC 61508 spezifisch für eine einzelne Branche
• ISO 27001 - Cybersicherheit für alle
• ISO 21434 - Cybersicherheit nach ISO/IEC 27001 für eine spezifische Branche
• [...]

Auch ein nicht in Gesetze, sondern Normen gepackter Stand der Technik kann dabei von Gerichten herangezogen werden, frei nach dem Motto: „Das hätten Sie wissen und einbeziehen müssen.“

„Verstehe ich nicht: es lief doch auf meinem lokalen Rechner einwandfrei. Keine Ahnung, warum es uns im echten Leben im Gesicht explodiert ist.“
Szene‑Spruch

In Kombination mit dem in anderen Staaten geltenden Recht kann es zu Konflikten kommen: der US‑Amerikanische Data Act beispielsweise ermöglicht US‑Behörden den Zugriff auf alle Daten, die von US‑Unternehmen auf Servern rund um die Welt gespeichert sind. Für viele Anwendungsfälle steht dies im eklatanten Widerspruch zu EU‑Recht, so dass der Kontakt zu US‑Unternehmen rechtlich mindestens riskant ist. Angesichts von Decoupling und Disconnect erscheint es ohnehin ratsam, europäische Anbieter zu nutzen. So einfach ist es natürlich nicht: top‑of‑the‑notch‑AI kommt aus den USA. Und was, wenn der gewählte EU‑Anbieter in die USA oder nach China verkauft wird? Dazu kommt, dass Freigabeprozesse u.a. vom Anwendungsfall und Unternehmen individuell abhängen. Verzwickte Sache, das alles. Und doch müssen wir einen gangbaren Weg finden.

Angemessen verstandenes DevOps bietet dazu mal wieder einen sehr guten Ansatz für den Anfang: Continous Integration und Deployment, die CI/CD‑Pipline. Ähnlich wie im Lean‑Management auf Shopfloor‑(=Produktions‑)Ebene beim Thema „Minimierung von Rüstzeiten“ stellt DevOps‑Kompetenz eine Reihe an Strategien und Werkzeugen zur Verfügung, um die Dramatik von Releases aufzulösen: Einfach durch eine große, automatisierte Häufigkeit samt Ökosystem: Paketmanager (Helm und Co.), GitOps und vieles mehr. Der Gesamtaufwand sinkt drastisch, die Anlässe für Konflikte auch. Zugegeben, diese mageren Sätze mögen noch nicht allzu überzeugend sein - ein Inhouse‑Infotag hat da mehr Chancen.

Freigaben unter Druck sind allerdings leider eher noch die Regel als die Ausnahme. Gut, wenn Sie abhängig beschäftigt und nicht in der Geschäftsleitung sind. Pauschale und zugleich gute Lösungen „one‑size‑fits‑all“ kann es nicht geben. Es gilt, die Welt und ihre Veränderlichkeit mit wachen Augen im Blick zu behalten und sinnvolles Vorgehen aktuell zu halten. Die Moderation hochwertiger Meetings in Verbindung mit einer offenen Unternehmenskultur erscheint angeraten. Nicht als Lippenbekenntnis und zum Abhaken von Checklisten, sondern mit dem Ziel echten Erkenntnis‑ und Qualitätsgewinns. Die Praxis zeigt: gar nicht so einfach! Manchmal kann ein Wirtschaftspsychologe zum entscheidenden Erfolgsfaktor werden.

Reden wir jetzt darüber!