Was noch vor wenigen Jahren vielfach als Buzzword galt, ist für die Entwicklung von Fahrzeugsoftware inzwischen eine operative Notwendigkeit: Continuous Integration und Continuous Delivery (CI/CD) bilden die Grundlage für kurze Entwicklungszyklen, automatisierte Tests und eine kontinuierliche Auslieferung von Software. Gerade im Software-Defined Vehicle (SDV) stoßen manuelle Integrationsprozesse, unregelmäßige Build-Zyklen und spät angesetzte Testkampagnen an ihre Grenzen, wie die beiden Autoren Günter Gromeier, EVP Automotive bei RT-RK und Nemanja Lukic, CTO bei RT-RK im Beitrag erklären.
Mit der zunehmenden Softwarekomplexität steigen auch die Anforderungen an Qualität und Absicherung. 2025 verzeichnete die Automobilindustrie das sechste Jahr in Folge steigende Rückrufzahlen aufgrund von Softwareproblemen [2]. Allein 2024 wurden in den USA mehr als 13 Millionen Fahrzeuge wegen softwarebezogener Mängel zurückgerufen – 35 Prozent mehr als im Vorjahr [3]. Verschärft wird dies durch immer anspruchsvollere Anforderungen in Bereichen wie autonomem Fahren/ADAS, KI-basierten Cockpits, V2X-Vernetzung und intelligentem Energiemanagement. Realisierbar werden diese Funktionen erst durch technologische Umbrüche wie Zentral- und Zonenrechnerarchitekturen, neuartige Middleware-Konzepte und kontinuierliche OTA-Updates – Treiber, welche die systemischen Abhängigkeiten und die Fehleranfälligkeit massiv potenzieren.
Noch vor kurzem galt CI/CD vielen als reines Buzzword. Heute ist es eine operative Notwendigkeit. Organisationen, die weiterhin auf manuelle Integrationszyklen, unregelmäßige Build-Zyklen und späte Testkampagnen setzen, werden in der Ära des Software-Defined Vehicle (SDV) unweigerlich den Anschluss verlieren. Wie in Bild 1 dargestellt, hat sich CI/CD zu jener grundlegenden Engineering-Disziplin entwickelt, um die herum der gesamte moderne Auslieferungsprozess automobiler Software aufgebaut ist. Legacy-CI/CD-Pipelines liefern zwar bewährten Wert, bringen aber versteckte Reibungsverluste mit sich: fragmentierte Verantwortlichkeiten und Tool-Silos. Die nächste Generation der Automotive Software Factory entsteht daher durch zwei aufeinander aufbauende Ausbaustufen: einen grundlegenden Ausbau der CI/CD-Pipeline auf den Stand der Technik und deren konsequente Erweiterung um Everything-as-Code (XaC).
Bild 1: Software-Release-Zyklus ohne und mit hochgradig automatisiertem CI/CD.
Warum sich der Ausbau lohnt: Der Preis später Fehler
Der wirtschaftliche Nutzen früher Fehlererkennung ist enorm. Erfahrungswerte belegen eine exponentielle Kostenkurve: Während ein Fehler in der lokalen Entwicklungsumgebung noch minimalen Aufwand erzeugt, kostet dessen Behebung in der Pre-Submit-Phase bereits das Fünffache, in der Post-Submit/CI-Phase das 15-Fache und auf Staging- bzw. Integrationssystemen das 50-Fache. Wird der Fehler erst in der Produktion aufgedeckt, explodieren die Kosten auf das 150-Fache.
Diese Rechnung wird durch branchenübergreifende Studien gestützt. Eine McKinsey/Oxford-Untersuchung großer IT-Projekte zeigt eine durchschnittliche Budgetüberschreitung von 45 Prozent, eine Terminüberschreitung von 7 Prozent und einen durchschnittlichen Wertverlust von 56 Prozent gegenüber der ursprünglich erwarteten Wertschöpfung [4]. Nur eines von 200 IT-Projekten erreicht Termin, Budget und Umfang gleichzeitig – das klassische „Iron Triangle“ aus Zeit, Kosten und Scope bleibt für die meisten Programme ein reines Zufallsprodukt statt einer verlässlichen Planungsgröße.
Für sicherheitskritische Automotive-Software mit ihren langen Entwicklungszyklen wiegen diese Zahlen besonders schwer. Frühzeitige, automatisierte Qualitätssicherung ist deshalb kein zusätzlicher Kostenfaktor, sondern eine Investition mit hohem Hebel – und genau das Fundament, auf dem die beiden folgenden Ausbaustufen aufbauen.
Stufe 1 – Ausbau der CI/CD-Pipeline
Der erste Schritt zur nächsten Generation der Software Factory besteht darin, die CI/CD-Pipeline vom reinen Build-Werkzeug zu einem durchgängigen Automatisierungs-Backbone für die gesamte Softwareauslieferung weiterzuentwickeln. Klassische Pipelines beschränken sich häufig auf automatisierte Builds und punktuelle Tests: Einzelne Änderungen wirken isoliert unauffällig, erzeugen jedoch erst bei der Integration gravierende Probleme. Eine modernisierte Pipeline validiert Änderungen dagegen stets im Systemkontext – jeder Änderungsschritt wird gegen die aktuelle, funktionsfähige Baseline geprüft, bevor er integriert wird.
Damit verändert sich grundlegend, wie Kontrolle im Entwicklungsprozess ausgeübt wird. Statt von isolierten Tools und dem Erfahrungswissen einzelner Experten abhängig zu sein, wird Qualitätssicherung standardisiert, transparent und ergebnisorientiert. Traceability wandelt sich von einer nachträglichen Compliance-Übung zu einem aktiven Instrument für Impact-Analysen und agiles Änderungsmanagement. Gleichzeitig hängt die Reproduzierbarkeit von Releases nicht mehr von fehleranfälligen manuellen Schritten ab, sondern ist inhärent in Versionierung, Konfiguration und Automatisierung verankert.
Konkret zeigt sich dieser Fortschritt in mehreren Bausteinen: automatisierten Merge-Gates mit paralleler Vorabprüfung (bei der jede Änderung gegen die stets stabile, „grüne“ Baseline getestet und in verifizierter Reihenfolge integriert wird), gehärteten und kontinuierlich erweiterten Testsuiten sowie tiefergehender statischer Codeanalyse zur Durchsetzung strenger Qualitäts-Gates. Ergänzt wird dies durch ein mehrstufiges Pipeline-Schema (Pull-Request-, Nightly-, Weekly- und Release-Pipelines) sowie eine hohe Skalierbarkeit mittels elastischer Verteilung von Build-Agenten und gezielter Virtualisierung.
Der Effekt lässt sich anhand der DORA-Metriken belegen, die in der Branche als Referenz für erstklassige Softwareauslieferung gelten. In einem realen Android-Projekt bei RT-RK führte diese Modernisierung zu einer 5- bis 10-fachen Steigerung der Deployment-Frequenz, einer Verkürzung der Lead-Time für Änderungen um den Faktor 5 bis 15 sowie einer Reduktion der Change-Failure-Rate um das 2- bis 4-Fache. Ein Ausbau der Pipeline liefert damit Geschwindigkeit, Kontrolle und belastbare Systemvalidierung. Für sich allein reicht er jedoch noch nicht aus, um diese Vorteile projektübergreifend reproduzierbar und über mehrere Teams und Standorte hinweg skalierbar zu machen – dafür braucht es die zweite Ausbaustufe.
Bild 2: Vorher/Nachher-Vergleich einer modernisierten CI/CD-Pipeline anhand zentraler DORA-Kennzahlen.
Stufe 2 – Erweiterung mit Everything-as-Code
Mit wachsender Reife entwickelt sich eine modernisierte CI/CD-Pipeline zur Software Factory weiter: eine ganzheitliche, industrialisierte DevOps-Umgebung, die Entwicklung, Integration, Testen und Deployment in einem konsistenten, automatisierten System vereint. Everything-as-Code (XaC) ist die konsequente Weiterführung dieses Ansatzes. Das Paradigma stellt sicher, dass alle Schlüsselelemente des gesamten Lebenszyklus als versionierte, maschinenlesbare Artefakte definiert sind – nichts wird mehr manuell konfiguriert, und Konfigurationen driften zwischen Projekten oder Teams nicht länger unbemerkt auseinander.
Die Bausteine von XaC lassen sich klar strukturieren:
- Docs-as-Code: Anforderungen, Architektur- und Testspezifikationen als maschinenlesbare Artefakte, die durchgängig mit Code und Build-Spezifikationen verknüpft sind – inklusive automatisierter Vollständigkeitsprüfung bei jedem Build.
- Project Configuration-as-Code: Projektorganisations- und Kollaborationsumgebungen (wie Task-Tracker und Wissensdatenbanken), Repository-Strukturen, Komponenten-Hierarchien und Zielplattformen als deklarative Projektmodelle, die Entwicklungsprozesse und Phasen im V-Modell definieren – inklusive automatisierter Synchronisation aller Projekt- und Managementsysteme.
- Infrastructure-as-Code: CI/CD- und Git-Server, Lizenzdienste und lokale Test-Serverfarmen als versionierte Infrastruktur-Artefakte, die physische wie virtuelle Ressourcen bereitstellen – inklusive automatisierter Orchestrierung und Bereitstellungslogik.
- Pipeline-as-Code: CI/CD-Workflows, Pull-Request-Validierungsstufen, Build- und Testabläufe sowie Release- und Dokumentationsgenerierungs-Prozesse als versionierte Pipeline-Skripte, die Code-Änderungen automatisiert verifizieren – inklusive definierter Quality-Gates und Merge-Bedingungen für MISRA-Konformität und strukturelle Testabdeckung.
- Environment-as-Code: Container-Definitionen und isolierte Werkzeugketten als reproduzierbare Entwicklungs- und Testumgebungen, die lokal und im CI-System bitgenau identisch ausgeführt werden – inklusive qualifizierter Toolchain-Versionierung zur Einhaltung von ISO-26262-Vorgaben.
- Monitoring & KPIs-as-Code: Grafana-Dashboards und Metriken-Konfigurationen als Code-generierte Artefakte, die Qualitäts- und Prozessdaten in Echtzeit aggregieren – inklusive automatisierter Statusberichte zu Traceability, Test-Pass-Rates und Meilenstein-Freigaben für ASPICE-Audits.
- Access Management-as-Code: Benutzerrollen, Projektberechtigungen und Tool-Zugriffsregeln als zentral versionierte Berechtigungskataloge, die Identity-Provider und Verzeichnisdienste (AD/SAML) anbinden – inklusive automatisierter Onboarding-Workflows für standort- und zuliefererübergreifende Teams.
Konsequent angewendet liefert XaC, was manuelle Konfiguration nie leisten konnte:
- Automatisiertes Projekt-Setup: Pipelines, Umgebungen und Dashboards werden direkt aus der zentralen Projektkonfiguration generiert.
- Schnellere Builds durch intelligentes Caching: Komponentenbasierte Pipelines bauen und testen ausschließlich die tatsächlich betroffenen Komponenten.
- Erzwungene Konsistenz bei jedem Pull-Request: Automatische Link-Prüfungen und Schema-Validierungen verhindern Konfigurationsfehler vor dem Merge.
- Aufwandsfreie Traceability: Traceability-KPIs und Abdeckungsübersichten entstehen automatisch direkt in der Pipeline.
- Kontinuierliche Audit-Readiness: Belastbare, audit-fähige Nachweise werden bei jedem Durchlauf fortlaufend und ohne manuellen Zusatzaufwand erzeugt.
Dabei werden Testergebnisse, SBOMs, Release-Manifeste und Konfigurationsbaselines fortlaufend validiert und automatisch zu einem reproduzierbaren, versionierten Release gebündelt.
Bild 3: Die sieben Bausteine von Everything-as-Code: Docs-, Project Configuration-, Infrastructure-, Pipeline-, Environment-, Monitoring & KPIs- und Access Management-as-Code.
Das Zusammenwirken: Warum beide Stufen gemeinsam die nächste Generation ausmachen
Die beiden Ausbaustufen entfalten ihren vollen Wert erst im Zusammenspiel. „Stufe 1 – Ausbau der CI/CD-Pipeline“ liefert Geschwindigkeit, Kontrolle und belastbare Systemvalidierung. Solange die zugrunde liegenden Konfigurationen jedoch nicht selbst als Code vorliegen, bleibt dieser Fortschritt projektgebunden und von einzelnen Expertinnen und Experten abhängig, die das jeweilige Setup kennen. „Stufe 2 – Erweiterung um Everything-as-Code“ liefert genau diese fehlende Reproduzierbarkeit, Auditierbarkeit und Skalierbarkeit über Teams und Standorte hinweg. Sie baut dabei auf einer bereits stabilen, automatisierten Pipeline auf – ohne ein tragfähiges CI/CD-Fundament liefe XaC ins Leere.
Erst im Zusammenspiel entsteht die eigentliche Software Factory der nächsten Generation: eine Umgebung, die sowohl schnell als auch reproduzierbar, sowohl kontrolliert als auch skalierbar ist. Requirements, Architektur, Code, Tests und Build-Spezifikationen bilden gemeinsam ein durchgängig versioniertes, maschinenlesbares Fundament, das sich über beliebig viele Projekte, Zulieferer und global verteilte Teams hinweg reproduzieren lässt.
Dieses Fundament bietet einen weiteren, strategischen Vorteil: Weil sämtliche Engineering-Artefakte als Code vorliegen und über standardisierte Pipelines verarbeitet werden, entsteht zugleich die Basis für den kontrollierten Einsatz weiterführender Automatisierung. Eine XaC-basierte Software Factory lässt sich gezielt auf den Einsatz KI-gestützter Werkzeuge und Agenten-Frameworks vorbereiten, ohne dass Traceability, Compliance und technische Kontrolle an Verlässlichkeit einbüßen. Wie dieser dritte Schritt konkret aussieht, ist Gegenstand eines eigenen, vertiefenden Beitrags. An dieser Stelle sei nur so viel festgehalten: Wer heute in moderne CI/CD und Everything-as-Code investiert, schafft damit zugleich die technische Grundlage für morgen.
Fazit
Die nächste Generation der Automotive Software Factory entsteht nicht durch einen einzelnen Technologiesprung, sondern durch das gezielte Zusammenwirken von CI/CD-Modernisierung und Everything-as-Code. Wer beide Stufen konsequent umsetzt, gewinnt nicht nur Geschwindigkeit und Kontrolle im Tagesgeschäft, sondern legt zugleich das reproduzierbare, auditierbare und skalierbare Fundament, auf dem sich künftige Automatisierungs- und KI-Frameworks sicher und nachvollziehbar aufsetzen lassen.
RT-RK ist ein führender Anbieter für Embedded-Software-Dienstleistungen mit Sitz in Novi Sad, Serbien, und blickt auf eine über 30-jährige Erfolgsgeschichte in den Bereichen Automotive, Consumer Electronics und vernetzte Systeme zurück. Mit praktischer Erfahrung in beiden Ausbaustufen – von der CI/CD-Pipeline-Modernisierung bis zur vollständigen Everything-as-Code-Transformation – unterstützt RT-RK OEMs und Tier-1-Zulieferer dabei, den Weg zur nächsten Generation ihrer Software Factory zu gestalten. (oe)
Literatur / Quellen
[1] McKinsey & Company (2020). The race for cybersecurity: Protecting the connected car in the era of new regulation. https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/the-race-for-cybersecurity-protecting-the-connected-car-in-the-era-of-new-regulation
[2] Tengler, S. (2025). Auto Software Recalls Approach Record For 6th Straight Year. Forbes. https://www.forbes.com/sites/stevetengler/2025/11/25/auto-software-recalls-approach-record-for-6th-straight-year/
[3] Mender.io (2025). How OTA updates reduce automotive recalls: A cost-saving strategy. https://mender.io/blog/how-ota-updates-reduce-automotive-recalls
[4] Bloch, M., Blumberg, S., & Laartz, J. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value#/
