AdaCore examines how embedded software teams can shorten feedback cycles through CI/CD, with investment in tooling and infrastructure, automation, compute, and software design.
The approach moves feedback closer to developers rather than relying on extended cycles of writing code, waiting for hardware, flashing firmware, and debugging.
Reducing the Haystack Effect
When feedback takes weeks, developers may have moved on to other work before learning that an earlier change introduced a defect. Reconstructing the original context can then be slow.
This “haystack effect” grows with the delay between introducing and identifying a bug. Per-developer feedback loops allow tests to run in an engineer’s workspace before changes reach a shared pipeline, preventing errors from compounding into technical debt that can take sprints to resolve.
Four Areas for CI/CD Investment
Functional CI/CD for embedded systems requires investment across four areas: tooling and infrastructure, automation, compute, and software design.
Reproducible build environments provide consistency regardless of local machine setup. Git-triggered pipelines can run quality checks without manual intervention, while cloud or containerized runners can scale with the team.
Software design is described as the area most often deprioritized and the most consequential. Abstraction layers can separate business logic from hardware-specific code, allowing integration tests to run on host machines using stubbed hardware. This means a full suite of system-level tests can run in a CI pipeline without a physical device in the loop, including for teams managing hardware availability constraints.
Automated Quality Gates
A CI/CD pipeline can automatically apply quality checks to every commit, including:
- Coding standards enforcement
- Unit test execution
- Static code analysis
- Security analysis
Pipelines should be containerized so developers do not have to debug local toolchain configurations while writing software. Dedicated infrastructure ownership can free engineers to focus on the product rather than maintaining the build environment.
For teams earlier in the process, open-source tooling provides a starting point, with the fundamentals achievable before commercial investment.
Making Metrics Useful
Test coverage, code complexity, and pass/fail trends should be visible to engineers rather than confined to management dashboards. Developers who can see their own metrics are in a position to improve them.
Proxy metrics such as lines of code or commit counts require caution. Optimizing for these measurements can change behavior without improving the underlying quality.
Testing the Process Through Onboarding
The time required for a new engineer to make a trivial code change and get it merged provides a benchmark for the development process.
Under one hour indicates that the process is working. Half a day is acceptable but worth examining, while longer indicates that onboarding and the pipeline need attention.
This measure covers environment setup, toolchain clarity, review workflows, and pipeline speed. A new developer who can make a small contribution on the first day is a reliable signal that the underlying system is healthy.
