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.