Continuous Everything – Brauchen wir das?

Shift Left und Continuous Everything bezeichnen die Praxis, Softwarequalität durch Automatisierung, kontinuierliche Integration und frühe Fehlererkennung messbar zu verbessern. Entscheidend sind zwei Metriken: wie schnell eine Änderung den Kunden erreicht und wie viele Fehlerreports eingehen. Beides sinkt nachweislich, wenn Teams schrittweise Autonomie und kulturellen Wandel vorantreiben statt zentrale Vorgaben umzusetzen.

Das Wichtigste in Kürze

• Trunk-Based Development glättet Defect-Spitzen beim Release messbar: Statt großer Fehlerpakete rund um Releases entsteht ein konstantes, niedrigeres Defect-Niveau im laufenden Betrieb.
• Kulturwandel in der Softwareentwicklung braucht Jahre, keine Quartale: Selbst mit gezielten Craftsmanship-Programmen dauert es zwei bis drei Jahre, bis neue Arbeitsweisen sich in Teams verankern.
• Autonomie schlägt Vorschrift: Teams, die selbst festlegen dürfen, wie viele offene Defects sie tolerieren, nehmen Qualitätsregeln deutlich besser an als Teams, denen eine Zero-Defect-Policy aufgezwungen wird.
• Zwei Metriken reichen, um Softwarequalität sinnvoll zu messen: Durchlaufzeit bis zum Kunden und Anzahl eingehender Fehlerreports zeigen zuverlässig, ob Prozessänderungen wirken.
• Wertstromanalyse vor jeder Prozessoptimierung schützt vor dem falschen Ansatzpunkt: Was sich als Problem anfühlt, ist selten das eigentliche Problem, oft steckt die verlorene Zeit in Wartezeiten auf andere Teams.

Continuous Everything bringt nur dann etwas, wenn man den Nutzen misst

Wer Continuous Integration, Delivery und Deployment einführt, steht früher oder später vor einer simplen Frage des Managements: Bringt das wirklich etwas? Tausende automatisierte Builds, ständige Testläufe, kontinuierliche Auslieferung. Das alles kostet erst einmal Geld und Zeit, bevor ein Effekt sichtbar wird.

Continuous Everything bedeutet, möglichst viele Schritte der Softwareentwicklung zu automatisieren und in einen kontinuierlichen Fluss zu bringen. Die Konferenzen sind voll von Tool-Herstellern und Erfahrungsberichten, wie sich das technisch umsetzen lässt. Die schwierigere Frage bleibt meist offen: Lässt sich der Qualitätsgewinn in Zahlen nachweisen?

Marco Achtziger formuliert dazu eine klare Position. Wer behauptet, eine Umstellung mache die Software besser, steht in der Bringschuld. Die gute Nachricht: Die nötigen Daten fallen ohnehin an. Source-Control-Systeme, Testausführungsprotokolle und Ticketsysteme liefern zeitgestempelte Informationen, die man über Jahre hinweg auswerten kann, ohne sie eigens zu erheben.

Warum technische Umstellungen vor allem ein Kulturproblem sind

Die Technik ist bei solchen Umstellungen das kleinste Problem. Das eigentliche Hindernis sind Gewohnheiten. Entwickler, die jahrelang mit einem schwergewichtigen Versionskontrollsystem gearbeitet haben, ändern ihr Vorgehen nicht freiwillig, nur weil ein neues Tool bereitsteht.

Eine Umstellung auf Continuous Everything ist deshalb in erster Linie eine Veränderung des Mindsets, nicht der Werkzeuge. Marco Achtziger stützt sich dabei auf das Motivationsmodell von Dan Pink mit seinen drei Hebeln: Mastery, Purpose und Autonomy. Wer diese drei Punkte adressiert, bringt Menschen dazu, aus eigenem Antrieb mitzuarbeiten.

Im konkreten Fall geschah das über sogenannte Craftsmanship-Programme. Die Teilnahme war komplett freiwillig, also Autonomie. Die Programme waren in Level aufgebaut, an denen sich Fähigkeiten sichtbar verbessern ließen, also Mastery. Und der Zweck jeder Maßnahme wurde erklärt, also Purpose.

Wie Freiwilligkeit funktioniert, wenn nicht alle mitziehen

Eine Silver Bullet gibt es nicht. Bei jedem Veränderungsprozess bleiben die letzten zehn Prozent zurück, die sich nicht überzeugen lassen. Marco Achtziger nennt das offen: Es gibt bis heute Kollegen, die das alte Versionskontrollsystem für das bessere halten. Das Ziel ist nicht, jeden mitzunehmen, sondern den Hauptteil der Leute zu erreichen.

Der wirksame Hebel sind die Meinungsmacher. In jeder Entwicklungs-Community gibt es einige Alpha-Tierchen, die gehört werden. Überzeugt man diese und macht sie zu Piloten, entstehen Multiplikatoren. Sie erzählen, was sie tun, und machen andere neugierig. Aus Neugier wird Teilnahme.

Dieser Weg braucht Zeit. Bis sich ein Craftsmanship-Programm in der Kultur etabliert hatte, vergingen zwei bis drei Jahre. Am Ende waren nahezu alle Teams beteiligt, etwa die Hälfte davon aktiv. Wer einen Kulturwandel erwartet, der von heute auf morgen greift, wird enttäuscht.

Wie Level konkrete Pain-Points aufgreifen

Die Level-Struktur eines Craftsmanship-Programms erfüllt zwei Aufgaben gleichzeitig. Sie definiert das erwartete Skillset von Entwicklern und Testern, und sie greift aktuelle Schmerzpunkte auf, die ohnehin gerade weh tun.

Ein Beispiel ist Continuous Integration. Eingeführt war sie schnell, aber die meisten Builds waren rot und niemand kümmerte sich darum. Ein bekannter Effekt. Die Level adressierten genau das, in aufeinander aufbauenden Stufen:

Flaky Tests waren ein eigener Schmerzpunkt. Tests, die je nach Mondphase oder Wochentag etwas anderes tun. Ein instabiler Test ist für sich genommen nicht schlimm. Schlimm ist, ihn zu ignorieren. Als zentraler Vorschlag diente ein Quarantäne-Build: Lässt sich ein flaky Test nicht in wenigen Stunden grün bekommen, wandert er aus der normalen Ausführung in die Quarantäne. So bleibt der reguläre Build grün.

Selbst gewählte Metriken wirken stärker als vorgegebene

Bei vielen Levels gaben die Programme keine konkrete Lösung vor, sondern forderten die Teams auf, selbst Vorschläge zu entwickeln. Ein Level verlangte etwa Metriken, mit denen die Teams ihren Code optimieren. Die erste Rückfrage lautete erwartbar: Welche Metriken sollen wir nehmen?

Die Antwort war: Sagt selbst. Macht euch Gedanken, welche Metrik euch etwas bringt. In den Diskussionen landeten am Ende viele bei etablierten Maßen wie Code Coverage oder der McCabe-Komplexität, konnten aber selbst erklären, warum. Genau das war das Ziel. Wer den Sinn einer Metrik versteht, setzt sie vernünftig ein, statt eine Zahl zu erfüllen, die eine Zentralabteilung vorgegeben hat.

Flaky Tests verschwinden nicht, man lernt sie zu behandeln

Ein stabiler Build ist kein Selbstzweck, und ein zu hundert Prozent grüner Build ist sogar verdächtig. Marco Achtziger bringt es auf den Punkt:

Wenn ein Build hundert Prozent grün ist, dann Glückwunsch, du hast stabile Tests. Die schlechte Nachricht ist: Anscheinend arbeitet keiner mehr. — Marco Achtziger

Wo Menschen arbeiten, entstehen Fehler, und daraus ergibt sich ein gewisser Bodensatz an Instabilität im System. Der Anspruch, jeden Test um jeden Preis zu stabilisieren, führt nicht weiter. Wichtig ist, Instabilität nicht zu ignorieren und einen Umgang damit zu finden, damit der Hauptteil der Builds grün bleibt.

In den Daten lässt sich dieser Lernprozess direkt ablesen. Kurz nach dem Start der Craftsmanship-Programme stieg der Anteil der Flaky Tests prozentual an, weil mehr Leute begannen, Tests zu schreiben. Danach, als das Bewusstsein für den Umgang mit instabilen Tests wuchs, fiel die Zahl wieder und pendelte sich auf niedrigem Niveau ein.

Zwei Metriken reichen, um Softwarequalität zu beurteilen

Für die Beurteilung von Softwarequalität sind im Kern nur zwei Metriken wirklich aussagekräftig: Wie lange dauert es, bis eine Änderung beim Kunden ankommt, und wie oft beschwert sich der Kunde über die Software.

Übersetzt heißt das Durchlaufzeit und Kundenfeedback, meist in Form von Defects oder Tickets. Beide Größen lassen sich aus vorhandenen Datentöpfen rekonstruieren und über Jahre verfolgen. Die Wirkung einer Umstellung zeigt sich nicht sofort, sondern über die Laufzeit mehrerer Versionen.

Bei der Durchlaufzeit war der Effekt deutlich. Nach der Umstellung von einem branchbasierten Ansatz auf Trunk-based Development sank die Zeit, bis eine Änderung beim Kunden landete, von Tagen in den Stundenbereich.

Wie Trunk-based Development die Defektkurve glättet

Trunk-based Development verändert nicht nur die Geschwindigkeit, sondern die Form der Defektkurve. Im branchbasierten Ansatz wurden alle Kunden aus unterschiedlichen Versionsbranches beliefert. Ein Fehler musste über mehrere Branches gefixt werden, und es war oft Rätselraten, an welchem Branchpunkt das Problem saß.

In diesem alten Modell traten die Defects in Spitzen auf, jeweils rund um ein Release. Für die Entwickler bedeutete das wiederkehrende Stoßbelastungen, die den normalen Arbeitsfluss massiv störten. Mit Trunk-based Development, bei dem seit zwei Jahren alle Kunden aus derselben Mainline beliefert werden, wurde aus der Spitzenkurve ein konstanter, flacher Verlauf auf niedrigem Niveau.

Legt man die Kurven übereinander, zeigt sich nicht nur die geglättete Form, sondern auch ein insgesamt tieferes Niveau. Die kontinuierliche Belastung im Trunk-based-Modell liegt unter dem, was am Ende der großen Release-Defektpakete übrig blieb.

Warum verknüpfbare Daten die Voraussetzung für jede Analyse sind

Die wichtigste Erkenntnis aus der Datenarbeit klingt banal: Daten müssen überhaupt erfasst und verknüpfbar sein. Oft genügen kleine Anpassungen am Tooling, um getrennte Datentöpfe zusammenführen zu können.

Ein konkretes Beispiel zeigt das Prinzip. Eine Datenbank protokollierte zwar, welche Tests in welchem Build gelaufen waren. Für die Verknüpfung mit den Änderungen im Source-Control-System fehlte aber ein Feld für die Versionsnummer. Diese Trivialität wurde nachgerüstet, und damit ließ sich die Analyse sogar historisch rekonstruieren.

Erst diese Verknüpfung machte die Flaky-Test-Erkennung möglich. Ein Build als Paket ist grobgranular, rot oder grün. Über die Verbindung bis auf Commit- und Testfall-Ebene lässt sich dagegen genau prüfen, welcher Test bei identischem Softwarestand unterschiedliche Ergebnisse liefert.

Wie sich ein verändertes Mindset im Alltag zeigt

Der sichtbarste Wandel betrifft nicht die Zahlen, sondern die Haltung der Entwickler. Wo früher ein zentrales Testteam und ein klassischer Graben zwischen Entwicklung und Test bestand, kam die jüngste Umstellung des Versionskontrollsystems auf Git auf Wunsch der Entwickler selbst. Ihre Bedingung lautete sinngemäß: Wenn Continuous Integration und die Tests funktionieren, dürft ihr das gerne ausrollen.

Auf Kundenseite spiegelt sich der Wandel im sinkenden Ticketaufkommen. Als Plattform-Lieferant erhält man das Feedback, dass sich die Plattform leichter integrieren lässt und mit jeder neuen Version weniger Anpassungsaufwand entsteht. Die Zahl der Fehlerreports geht messbar zurück, während die Plattform nachweislich weiter genutzt wird.

Warum die Zero-Defect-Policy scheiterte und Bug Jail funktionierte

Nicht jedes Experiment trug. Eine Zero-Defect-Policy, die vorschrieb, bei jedem Defect sofort alles andere liegen zu lassen, kam bei den Teams schlecht an. Marco Achtziger würde sie nie wieder einführen.

Die nächste Iteration drehte das Prinzip um. Unter dem Namen Bug Jail durften die Teams selbst festlegen, wie viele Defects sie zulassen, bevor sie die Entwicklung stoppen. Konservativere Teams nannten maximal zwei, andere fünf. Trotz dieser Heterogenität funktionierte der Ansatz deutlich besser.

Der Unterschied lag in der Autonomie. Sobald die Teams selbst über die Schwelle nachdachten, kümmerten sie sich früher um eingehende Defects. Die Lehre daraus lässt sich auf jede Veränderung übertragen: Nenne das Ziel und das Problem, aber überlasse den Weg dorthin dem Team.

Wo der nächste Hebel liegt: Testausführung optimieren

Der aktuelle Engpass ist die schiere Masse an Testausführung. Eine aussagekräftige Metrik dafür ist die Testausführungszeit pro realem Monat. Im Idealfall läge dieser Wert bei eins, eine Maschine, die rund um die Uhr alle Tests durchläuft. Tatsächlich nähert sich der Wert dem rechnerischen Maximum an Maschinenkapazität an, weil in einem regulierten Bereich viele Tests vorgeschrieben sind.

Der Lösungsansatz ist ein Machine-Learning-System, das für eine bestimmte Source-Code-Änderung die Tests vorhersagt, die am wahrscheinlichsten fehlschlagen. Damit ließe sich etwa ein Gated Check-in beschleunigen: Der Lauf kann beim ersten fehlschlagenden Test abbrechen oder bei einer festgelegten Schranke fehlschlagender Tests. So sinkt die benötigte Maschinenzahl wieder auf ein vertretbares Maß.

Wo du anfangen solltest: die Wertstromanalyse

Vor jeder Umstellung steht die Wertstromanalyse aus dem Lean-Umfeld. Bevor du irgendetwas änderst, schreibst du die Zahlen auf und schaust, wo deine Zeit tatsächlich verloren geht. Die Erfahrung zeigt: Was man am Anfang für das Problem hält, ist fast nie das eigentliche Problem.

Häufig sind es Trivialitäten, das Warten auf ein anderes Team etwa, die die meiste Zeit fressen. Hast du den Wertstrom vor dir, adressierst du zuerst den größten Zeitfresser, der sich auch wirklich beeinflussen lässt.

Plane Geduld ein und iteriere. Wer Dinge öfter und schneller tut, verändert damit die Problemlage selbst, und nach einiger Zeit lohnt ein erneuter Blick auf die alte Problemliste. Manche Schritte werden zunächst sogar langsamer. Trunk-based Development verlangt vom einzelnen Entwickler mehr Nachdenken, etwa über Rückwärtskompatibilität.

Deshalb gilt: Betrachte immer die komplette Kette, nicht den einzelnen Schritt. Nur weil ein Teilschritt kurzzeitig langsamer wird, heißt das nicht, dass die gesamte Kette langsamer wird. Im Gegenteil, sie wird schneller.