How GitLab transforms embedded systems testing cycles

Embedded developers know this cycle well: write code, wait days or weeks to test on a hardware test bench, discover bugs, fix them, then wait again. Virtual testing environments promise faster feedback, but most implementations create new problems such as environment sprawl and escalating costs.

GitLab's managed lifecycle environments solve these virtual testing challenges. Through virtual environment automation, GitLab accelerates embedded development cycles without the configuration complexity and cost overruns.

Virtual testing challenges

Virtual testing environments — simulated hardware setups that replicate embedded system behavior and real-world conditions — offer the potential to reduce hardware bottlenecks. Teams can test firmware on simulated processors, run model-in-the-loop (MIL) tests in MATLAB/Simulink, or verify software on virtual embedded systems without waiting for physical hardware access.

However, teams often implement virtual environments using one of two common approaches, both of which create unsustainable challenges.

Flawed approach 1: Pipeline lifecycle environments

Pipeline lifecycle environments re-create the entire testing setup for every CI/CD run. When code changes trigger your CI/CD pipeline, the system provisions infrastructure, installs software simulations, and configures everything from scratch before running tests.

This approach works for simple scenarios but becomes inefficient as complexity rises. Consider software-in-the-loop (SIL) testing in a complex virtual environment, for example. Each pipeline run requires complete environment re-creation, including virtual processor provisioning, toolchain installations, and target configurations. These processes can eat up considerable time.

Moreover, as embedded systems require more sophisticated virtual hardware configurations, the provisioning costs quickly add up.

To avoid these rebuild costs and delays, many teams turn to long-lived environments that persist between test runs. But they come with downsides.

Flawed approach 2: Long-lived environments

Long-lived environments persist indefinitely to avoid constant rebuilding. Developers request these environments from IT or DevOps teams, wait for approval, then need someone to manually provision the infrastructure. These environments are then tied to individual developers/teams rather than specific code changes, and they support ongoing development work across multiple projects.

While this eliminates rebuild overhead, it creates environment sprawl. Environments accumulate without a clear termination date. Infrastructure costs climb as environments consume resources indefinitely.

Long-lived environments also suffer from "config rot" — environments retain settings, cached data, or software versions from previous tests that can affect subsequent results. A test that should fail ends up passing due to the residue of previous testing.

Ultimately, managing long-lived environments is a manual process that slows development velocity and increases operational overhead.

GitLab offers a third approach through “managed lifecycle environments.” This approach captures the benefits of both long-lived and pipeline lifecycle environments while avoiding the drawbacks.

Solution: Managed lifecycle environments

GitLab's managed lifecycle environments tie virtual testing setups to merge requests (MRs) rather than pipeline runs or individual developers. You can also think of them as “managed MR test environments.” When you create an MR for a new feature, GitLab automatically orchestrates the provisioning of necessary virtual testing environments. These environments persist throughout the entire feature development process.

Key benefits

• Persistent environments without rebuilding: The same virtual environment handles multiple pipeline runs as you iterate on your feature. Whether you're running MIL tests in MATLAB/Simulink or SIL tests on specialized embedded processors, the environment remains configured and ready.

• Automatic cleanup: When you merge your feature and delete the branch, GitLab automatically triggers environment cleanup, eliminating environment sprawl.

• Single source of truth: The MR records all build results, test outcomes, and environment metadata in one location. Team members can track progress and collaborate without shuffling between different tools or spreadsheets.

Watch this overview video to see how managed lifecycle environments work in practice:

GitLab automates the entire testing workflow. Each time you run firmware tests, GitLab orchestrates testing in the appropriate virtual environment, records results, and provides full visibility into every pipeline run. This approach transforms complex virtual testing from a manual, error-prone process into automated, reliable workflows.

The result: Teams get reusable environments without runaway costs. And they increase efficiency while maintaining clean, isolated testing setups for each feature.

See a demonstration of managed lifecycle environments for testing firmware on virtual hardware:

Business impact

GitLab's managed lifecycle environments deliver measurable improvements across embedded development workflows. Teams running MIL testing in MATLAB/Simulink and SIL testing on specialized processors like Infineon AURIX or BlackBerry QNX systems no longer face the tradeoff between constant environment rebuilds or uncontrolled environment sprawl. Instead, these complex virtual testing setups persist throughout feature development while automatically cleaning up when complete, enabling:

• Faster product development cycles
• Shorter time-to-market
• Lower infrastructure costs
• Higher quality assurance

Start transforming virtual testing today

Download “Unlocking agility and avoiding runaway costs in embedded development” for a deeper exploration of managed lifecycle environments and learn how to accelerate embedded development workflows dramatically.