What was widely regarded as just a buzzword just a few years ago has now become an operational necessity for vehicle software development: Continuous Integration and Continuous Delivery (CI/CD) form the foundation for short development cycles, automated testing, and continuous software delivery. In the context of the Software-Defined Vehicle (SDV) in particular, manual integration processes, irregular build cycles, and late-stage testing campaigns are reaching their limits, as the two authors—Günter Gromeier, EVP Automotive at RT-RK, and Nemanja Lukic, CTO at RT-RK—explain in this article.
As software complexity increases, so do the demands on quality and validation. In 2025, the automotive industry recorded its sixth consecutive year of rising recall numbers due to software issues [2]. In 2024 alone, more than 13 million vehicles were recalled in the U.S. due to software-related defects—a 35 percent increase over the previous year [3]. This situation is exacerbated by increasingly demanding requirements in areas such as autonomous driving/ADAS, AI-based cockpits, V2X connectivity, and intelligent energy management. These functions are only made possible by technological breakthroughs such as central and zone computer architectures, innovative middleware concepts, and continuous OTA updates—drivers that massively increase systemic dependencies and susceptibility to errors.
Until recently, CI/CD was considered by many to be nothing more than a buzzword. Today, it is an operational necessity. Organizations that continue to rely on manual integration cycles, irregular build cycles, and late testing campaigns will inevitably fall behind in the era of the Software-Defined Vehicle (SDV). As shown in Figure 1, CI/CD has evolved into the fundamental engineering discipline around which the entire modern automotive software delivery process is built. While legacy CI/CD pipelines deliver proven value, they also come with hidden inefficiencies: fragmented responsibilities and tool silos. The next generation of the Automotive Software Factory is therefore emerging through two sequential phases of development: a fundamental upgrade of the CI/CD pipeline to the state of the art and its consistent expansion to include Everything-as-Code (XaC).
Figure 1: Software release cycle with and without highly automated CI/CD.
Why the Upgrade Is Worth It: The Cost of Late Mistakes
The economic benefits of early error detection are enormous. Empirical data show an exponential cost curve: While an error in the local development environment still incurs minimal effort, fixing it in the pre-submit phase already costs five times as much, in the post-submit/CI phase 15 times as much, and on staging or integration systems 50 times as much. If the bug is not discovered until the production environment, the costs skyrocket to 150 times the original amount.
This assessment is supported by cross-industry studies. A McKinsey/Oxford study of large IT projects shows an average budget overrun of 45 percent, a schedule overrun of 7 percent, and an average loss of 56 percent in value compared to the originally expected value creation [4]. Only one in 200 IT projects meets its deadline, budget, and scope simultaneously—the classic “Iron Triangle” of time, cost, and scope remains, for most programs, a matter of chance rather than a reliable planning metric.
For safety-critical automotive software, with its long development cycles, these figures carry particular weight. Early, automated quality assurance is therefore not an additional cost factor, but rather a high-impact investment—and precisely the foundation upon which the following two expansion stages are built.
Phase 1 – Expansion of the CI/CD pipeline
The first step toward the next generation of the software factory is to evolve the CI/CD pipeline from a mere build tool into an end-to-end automation backbone for the entire software delivery process. Traditional pipelines are often limited to automated builds and ad hoc tests: Individual changes may seem insignificant in isolation, but they can cause serious problems once integrated. A modernized pipeline, on the other hand, always validates changes within the system context—each change is checked against the current, functional baseline before it is integrated.
This fundamentally changes how control is exercised in the development process. Instead of relying on isolated tools and the experiential knowledge of individual experts, quality assurance becomes standardized, transparent, and results-oriented. Traceability evolves from a retroactive compliance exercise into an active tool for impact analysis and agile change management. At the same time, the reproducibility of releases no longer depends on error-prone manual steps but is inherently embedded in versioning, configuration, and automation.
Specifically, this progress is evident in several key components: automated merge gates with parallel pre-checks (in which every change is tested against the consistently stable, “green” baseline and integrated in a verified order), hardened and continuously expanded test suites, and in-depth static code analysis to enforce strict quality gates. This is complemented by a multi-stage pipeline scheme (pull request, nightly, weekly, and release pipelines) as well as high scalability achieved through elastic distribution of build agents and targeted virtualization.
This effect is demonstrated by the DORA metrics, which are considered the industry benchmark for world-class software delivery. In a real-world Android project at RT-RK, this modernization led to a 5- to 10-fold increase in deployment frequency, a 5- to 15-fold reduction in lead time for changes, and a 2- to 4-fold reduction in the change failure rate. Expanding the pipeline thus delivers speed, control, and robust system validation. On its own, however, it is not yet sufficient to make these benefits reproducible across projects and scalable across multiple teams and locations—that requires the second phase of expansion.
Figure 2: Before-and-after comparison of a modernized CI/CD pipeline based on key DORA metrics.
Level 2 – Expansion with Everything-as-Code
As maturity grows, a modernized CI/CD pipeline evolves into a software factory: a holistic, industrialized DevOps environment that unifies development, integration, testing, and deployment into a consistent, automated system. Everything-as-Code (XaC) is the logical extension of this approach. This paradigm ensures that all key elements of the entire lifecycle are defined as versioned, machine-readable artifacts—nothing is configured manually anymore, and configurations no longer drift apart unnoticed across projects or teams.
The building blocks of XaC can be clearly structured:
- Docs-as-Code: Requirements, architecture, and test specifications as machine-readable artifacts that are consistently linked to code and build specifications—including automated completeness checks with every build.
- Project Configuration-as-Code: Project organization and collaboration environments (such as task trackers and knowledge bases), repository structures, component hierarchies, and target platforms as declarative project models that define development processes and phases in the V-model—including automated synchronization of all project and management systems.
- Infrastructure-as-Code: CI/CD and Git servers, licensing services, and local test server farms as versioned infrastructure artifacts that provision both physical and virtual resources—including automated orchestration and deployment logic.
- Pipeline-as-Code: CI/CD workflows, pull request validation stages, build and test sequences, and release and documentation generation processes as versioned pipeline scripts that automatically verify code changes—including defined quality gates and merge conditions for MISRA compliance and structural test coverage.
- Environment-as-Code: Container definitions and isolated toolchains as reproducible development and test environments that run identically—down to the bit—both locally and in the CI system—including qualified toolchain versioning to comply with ISO 26262 requirements.
- Monitoring & KPIs-as-Code: Grafana dashboards and metrics configurations as code-generated artifacts that aggregate quality and process data in real time—including automated status reports on traceability, test pass rates, and milestone approvals for ASPICE audits.
- Access Management-as-Code: User roles, project permissions, and tool access rules as centrally version-controlled permission catalogs that integrate with identity providers and directory services (AD/SAML)—including automated onboarding workflows for teams spanning multiple locations and suppliers.
When used consistently, XaC delivers what manual configuration could never achieve:
- Automated Project Setup: Pipelines, environments, and dashboards are generated directly from the central project configuration.
- Faster Builds Through Intelligent Caching: Component-based pipelines build and test only the components that are actually affected.
- Enforced Consistency with Every Pull Request: Automatic link checks and schema validations prevent configuration errors before the merge.
- Effortless traceability: Traceability KPIs and coverage reports are generated automatically right within the pipeline.
- Continuous audit readiness: Reliable, audit-ready evidence is generated continuously with every run, without any additional manual effort.
In this process, test results, SBOMs, release manifests, and configuration baselines are continuously validated and automatically bundled into a reproducible, versioned release.
Bild 3: Die sieben Bausteine von „Everything-as-Code“: Docs-as-Code, Project Configuration-as-Code, Infrastructure-as-Code, Pipeline-as-Code, Environment-as-Code, Monitoring & KPIs-as-Code und Access Management-as-Code.
Synergy: Why Both Stages Together Define the Next Generation
The two implementation phases only realize their full value when working together. “Phase 1—Expansion of the CI/CD Pipeline” delivers speed, control, and robust system validation. However, as long as the underlying configurations are not themselves available as code, this progress remains project-specific and dependent on individual experts who are familiar with the respective setup. “Phase 2—Expansion to Everything-as-Code” provides precisely this missing reproducibility, auditability, and scalability across teams and locations. It builds on an already stable, automated pipeline—without a solid CI/CD foundation, XaC would come to nothing.
It is only through this synergy that the true next-generation software factory emerges: an environment that is both fast and reproducible, as well as controlled and scalable. Requirements, architecture, code, tests, and build specifications together form a consistently versioned, machine-readable foundation that can be reproduced across any number of projects, suppliers, and globally distributed teams.
This foundation offers another strategic advantage: Because all engineering artifacts exist as code and are processed via standardized pipelines, it simultaneously lays the groundwork for the controlled implementation of advanced automation. An XaC-based software factory can be specifically prepared for the use of AI-powered tools and agent frameworks without compromising the reliability of traceability, compliance, and technical control. What this third step looks like in practice is the subject of a separate, in-depth article. For now, let’s just note this: Anyone investing in modern CI/CD and Everything-as-Code today is simultaneously laying the technical foundation for tomorrow.
Fazit
The next generation of the Automotive Software Factory is not the result of a single technological leap, but rather the targeted synergy of CI/CD modernization and “Everything-as-Code.” Those who consistently implement both phases not only gain speed and control in their day-to-day operations but also lay the reproducible, auditable, and scalable foundation upon which future automation and AI frameworks can be built securely and transparently.
RT-RK is a leading provider of embedded software services based in Novi Sad, Serbia, with a track record of success spanning more than 30 years in the automotive, consumer electronics, and connected systems sectors. With hands-on experience at both stages—from CI/CD pipeline modernization to a complete “Everything-as-Code” transformation—RT-RK helps OEMs and Tier 1 suppliers chart the path to the next generation of their software factory. (oe)
Bibliography / Sources
[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#/
