Continuous Building und Integration : die CB/CI/CD‑Pipeline aus DevOps

Erst einmal kurz zur Doppelbedeutung von Integration: Man kann darunter das Zusammenschalten aller Units einer Software zu einem System verstehen. Oder es bezeichnet zusätzlich die Implementierung auf der für den Einsatz vorgesehenen programmierbaren Elektronik wie ASICs, FPGAs, CPLDs, Mikroprozessoren oder auch ganze Controller. Es ist möglich, dass der Safety‑Fall den Einbezug von IEC 61508 oder seiner branchenspezifischen Ausformungen wie ISO 26262 einfordert. Oder auch die ISO/IEC 27001 oder auch eine ganze Liste an (langfristig durchaus sinnvollen) EU‑Vorgaben. Mehr dazu an anderer Stelle oder in einem Inhouse‑Seminar. Ist die Entscheidung für einen Baustein gefallen und sind die Bestellungen aufgrund bisweilen sehr langer Lieferzeiten frühzeitig raus und das kundenseitige Lastenheft liegt vor, sind der Agilität erste Grenzen gesetzt. So viel vorab.

Nehmen wir jetzt an, wir haben das Geschäftsziel der Software sauber und konform zum Kriteriensystem S⁴M²A⁴R²T² STUPF²E²L²N+V definiert. Vielleicht enthält es sogar eine echte, disruptive Innovation oder auch nicht. Die anspruchsvolle Phase des Requirements Engineering ist maximal sorgfältig durchlaufen und war von Einfallsreichtum geprägt, erzeugt durch Nutzung der sieben Vollständigkeitsebenen, der 80 Fragetechniken in projektspezifischer Formulierung und bestem Design Thinking. Aktives Zuhören und gezieltes Paraphrasieren haben wichtige Erkenntnisse und Heureka‑Momente beigesteuert. Die Spezifikation der Software enthält soger eine to‑let‑Liste und darf insgesamt als perfekt gelungen bezeichnet werden. In hochwertig moderierten Meetings wurden Schnittstellen umsetzbar definiert. Es wurde eine Qualitäts‑Architektur geschaffen und die Module/Methoden/Unterprogramme/Klassen in kleine Häppchen im Sinne der Grundprinzipien guten Software Engineerings dicht an Microservices unterteilt. Alles ist gut.

Der Startschuss fällt. Alle arbeiten nach bestem Wissen und Gewissen an ihren Teilaufgaben. Ein Jahr später erfolgt der Versuch, daraus eine lauffähige Software herzustellen: der erste Big‑Bang‑Build erfolgt. Erfahrene Entwickler schlafen in dieser Nacht schlecht. Es ist klar, wie das meist ausgeht, oder? Ein Merge‑Hell bricht über alle herein. Natürlich bricht der Build ab, liefert Berge an Fehlermeldungen, es setzt eine kreative Phase des Blame‑Stormings ein. Tickets sind mit Feature‑Requests überfüllt und werden damit zu Epics. Ticket‑Pingpong setzt ein - immerhin muss klar gemacht werden, dass die Anderen auch noch viel Unerledigtes auf dem Tisch haben. Aus Ab‑Teilungen (bewusst so geschrieben) wird ein Wir‑gegen‑Die. Völlig normal, völlig menschlich, wie Studien zeigen. Überleben ohne allzu viel Gesichtsverlust verbraucht ab jetzt einen guten Teil der kognitiven Kapazitäten, die anders besser eingesetzt wären. Man schiebt sich gegenseitig die vielen schwarzen Peter zu, die Stimmung kippt in Richtung zwischenmenschlicher Konflikte, Groll und Ärger. Nach einiger Zeit warten alle mit ihren Änderungen ab, bis sich ein belastbarer Zwischenstand herausbildet. Was nicht so recht passieren will. Das gemeinsame Bauen einer Brücke aus Papier im Wald als Teambuilding‑Maßnahme macht alles nur noch schlimmer. Aber die Lage ist seitens der Führungskräfte deswegen noch lange nicht passiv hinzunehmen, in der Qualität der Überwindung dieser und anderer Situationen entscheidet sich der Wettbewerb. Ein hinzugezogener Wirtschaftspsychologe hat allerdings seine liebe Mühe, aus der toxischen Kultur ein konstruktives Miteinander wenigstens halbwegs herzustellen und erfreut sich während dessen nur einer recht beschränkten Beliebtheit 🙄. Na ja, ein Teil des Honorars ist dann halt Schmerzensgeld. Kann man so machen. Die lauffähige Software ist später kreuz und quer von hektisch erzeugten Workarounds im jeweils eigenen Zuständigkeitsbereich durchzogen, die Entropie schon zu Beginn des Einsatzes im Betrieb des Produktivsystems hoch. Das sind natürlich einander ergänzende Erfahrungen aus vielen Unternehmen überspitzt zusammengestellt.

Einmal abgesehen vom überperfekt‑illusorischen Start dieses Textes - die chaotische Phase ist in vielen Unternehmen wohlbekannt, wird recht unterschiedlich gelebt und lässt sich wohl auch nur selten vollständig vermeiden. Wenn möglich, schalten wir auf Continuous Building, Integration und Deployment, die CB/CI/CD‑Pipeline. Meint: sobald eine Änderung im Code vom Entwickler freigeschaltet wird, startet automatisch ein neuer Build, organisiert auf einem CI‑Server, z.B. aus der Git‑Welt. Natürlich sollte die Pipeline nicht manuell laufend neu erfunden werden, sondern als KVP‑Skript und damit als deklarative Pipeline, vielleicht in YAML oder XML erzeugt werden. Jeder Entwickler kann so Fehlermeldungen direkt auf seinen Code beziehen und Fehler sofort beheben. Das selbstverständlich hochwertige Versionsmanagement (nicht zu verwechseln mit dem Konfigurationsmanagement), vielleicht sogar ein semantisches Versionieren, hält stets die letzte baubare Version des Softwaresystems zur Verfügung vor. Werden automatisierte statische und dynamische Tests, möglichst skalierbar und reproduzierende Ergebnisse liefernd, zu Funktionalität und Security in die Pipeline integriert, steigen Effizienz der Entwickler und die Qualität der Software weiter. KI eignet sich dabei besonders für die Entwicklung von Testsoftware: falsch‑positive Ergebnisse aufgrund von geschickt verborgenen Halluzinationen erzeugen zwar Aufwand zur Erkennung des Problems, gefährden jedoch nicht das Ergebnis. Ok, anders wäre besser und dazu gibt es ja prima Tools.

Und schon wieder Vorsicht: Menschen verlieben sich in Tools und ihre Meinungen dazu. Spätere Heirat nicht ausgeschlossen. Tools wechseln und entwickeln sich allerdings wie Schall und Rauch, mentale Flexibilität kennzeichnet die wirklich guten Leute. Es sind die unternehmerischen Grundlagen und Ziele, anhand derer die Tools temporär auszuwählen sind. Nicht umgekehrt. Man beachte auch: Plugins eines großen Ökosystems sind einerseits hilfreich, bringen aber in zunehmendem Maße Security‑Risiken mit. Wie bei jedem anderen Schritt auch, ist die Aushandlung einer zum Ziel führenden und übereinstimmend beschlossenen Strategie der wirkungsstärkste Faktor.

Reden wir darüber!