No More “It Works on my Machine”: Containerized Builds for Embedded Teams
Embedded development environments are often brittle—tied to specific host setups, compiler versions, and SDKs. As teams grow or go remote, these inconsistencies cause environment drift, onboarding delays, and audit challenges. This session presents a technical blueprint for adopting containerized development environments to eliminate these issues.
We will demonstrate how to:
- Package cross-compilation toolchains, static analyzers, coverage tools, and test frameworks inside Docker or DevContainer setups
- Support real hardware debugging via USB or JTAG passthrough inside containers
- Maintain full CI/CD compatibility across hybrid MCU/MPU pipelines
We will also explore techniques for:
- Layering containers to support multiple targets
- Enforcing secure development practices with container scanning
- Maintaining compliance checkpoints inside the build
Real-world use cases will highlight improved developer onboarding, reproducibility, and security posture across distributed teams.
What this presentation is about and why it matters
How do embedded teams stop build environments from drifting, especially when hardware, toolchain versions, licensing, and compliance expectations all vary from project to project? Shawn Prestridge approaches that problem with a practical walkthrough of containerized builds, framed around embedded CI/CD and DevSecOps rather than abstract DevOps theory. He connects the idea to day-to-day realities like onboarding, reproducibility, static analysis, and functional safety workflows, with examples drawn from tools such as Docker, CMake, Visual Studio Code, and common CI systems. This is a good fit for engineers and team leads who want a grounded look at making builds repeatable across people, machines, and architectures.
Who will benefit the most from this presentation
- Embedded developers who are fighting “works on my machine” build drift across a team
- Build and release engineers who need more repeatable CI/CD pipelines for firmware
- Technical leads planning onboarding for new hires or shared development containers
- Engineers working on regulated or functional-safety-adjacent projects
- Teams supporting multiple architectures, toolchain versions, or remote contributors
What you need to know
Useful background, though not strictly required:
- Basic familiarity with embedded development workflows
- Some exposure to version control and CI/CD concepts
- Awareness of build tools, test automation, or container concepts
- Optional: experience with CMake, Docker, or Visual Studio Code
Glossary (terms used in this talk)
- CI/CD (Continuous Integration/Continuous Deployment): An automated pipeline practice for continuously integrating code changes, running verification, and optionally releasing software.
- RTOS (Real-Time Operating System): An operating system designed to provide predictable timing behavior for real-time applications.
- MISRA: A widely used set of guidelines for writing safer and more portable C and C++ code in embedded systems.
- Containerized builds: A build setup packaged inside a container so the toolchain, dependencies, and environment stay consistent across machines. This helps reduce differences caused by local configuration drift.
- Development container: A container used as a full development environment, often including editor extensions, build tools, and project-specific configuration. It gives different developers a shared starting point while keeping the host machine isolated.
- Runner: An execution agent in a CI system that picks up jobs such as builds, tests, or analysis steps. Runners can be hosted locally or in the cloud, depending on the workflow.
- Dockerfile: A plain-text file that defines the steps and contents for building a Docker container image; it specifies the base image, commands, and files to include.
- devcontainer.json: A configuration file used by development container systems (for example VS Code Dev Containers) that defines the container to use and editor extensions and settings to apply inside that container.
Toolbox (mentioned in this talk)
- Bitbucket: A Git-based source code hosting and collaboration platform from Atlassian.
- GitLab: A web-based DevOps platform for source control, CI/CD, and project collaboration.
- GitHub: A web-based platform for hosting Git repositories and collaborating on software development.
- Jenkins: An automation server commonly used to build, test, and deploy software in CI/CD pipelines.
- Git: A distributed version control system for tracking changes in source code and coordinating collaborative development.
- Visual Studio Code: A lightweight source code editor with broad language support and extension-based integration. It is often used for embedded development and can pair well with containerized workflows.
Final thoughts
Practical and workflow-focused, this session gives you a way to think about builds as something you can standardize, automate, and share across a team. The main value is a clearer mental model for where containers fit in embedded delivery, especially when reproducibility, onboarding, and traceability matter. It will help build engineers, firmware developers, and technical leads who are trying to reduce friction without forcing everyone into the same editor or the same habits. The underlying message is simple: if the environment is part of the problem, treat it like part of the system.
This overview is AI-generated from the session transcript. Spot an issue? Let us know.
CI/CD pipelines use our CX products which are cloud-based licenses of our tooling, e.g. CXARM for cloud-based build tools for Arm. We host the license server for you, and as one build action finishes, it becomes available for the next thing in your pipeline; it doesn't care if it's in the same container or another container, multiple runners, etc. What this means in a practical sense is that none of the licenses are tied to specific hosts/containers/runners/etc. Therefore, it solves your problem in a cloud-native way!
Thank you for this presentation. Can you upload the slides?
They should be uploaded now!
Thanks for the interesting roundup. As someone who uses CI/CD for embedded development I can agree to your arguments. As an addition I would mention it's also possible to add integration and burn in tests on real hardware to the workflow. That makes pre testing of new releases very convenient even though it can be a pain to set it up.
I learned in your talk about containers with integrated secure boot setup etc. I don't know how that looks like but now that I know it's out there I will look out for it.








Thank you for the well-researched introduction to containerized CI/CD. You mention that this approach also "takes care of licensing headaches". Could you expand on this? You mention that the "licensing basically figures itself out" (12:52), but it is not clear to me how this might work.
In my case, we have specifically NOT migrated some legacy builds to containerized CI/CD because they rely on licensed compilers that are bound to specific build hosts, and will therefore NOT run inside containers on "random" (and potentially isolated) build hosts. How do your containerized builds take care of this? My main issues are currently with Microchip compilers, but an example utilizing IAR compilers will also be helpful.
Many thanks