Docker is a great solution for controlled development environments.
One of the great things about Docker is specifying an entire environment. You create a list that includes the OS, along with all of the tools, accessories, scripts, and whatever else you want to appear in that image. Docker, in turn, goes and collects all of those components and builds a custom image to match your list.
The real value here is for development environments that need to be controlled for reproducibility and detailed documentation.
We all love flexibility. We can set things up to make tasks easier, run faster, use less space, or just make things look nicer. Many modern tools allow us to customize all kinds of features in our development environments. Prefer editing in VIM mode? No problem, you can enable that in many IDEs. How about some shortcuts for commonly used tools or commands? Again, no problem. There’s a configuration window for that. Most of that is fine. That is, until it unexpectedly affects what you’re building.
Perhaps you use the same command-line arguments all the time. So, you set an environment variable to let the tool know you want to always configure itself before executing commands to save the extra typing each time. Maybe you have some libraries you frequently use, so you add their paths to the linker’s environment variables. Maybe you downloaded the latest version of the compiler, and you attempted to build a new project. Now you’re getting different results than the guy next to you. There are many different ways small changes can affect the development environment. Some are obvious, and some are not so obvious.
Tracking down these changes becomes an even bigger headache. You have to collect all the relevant information from each environment and try to compare the details to see where they differ. Next, make those changes, and repeat the process all over again and again until everything works as expected. This is a very time-consuming process, with the possibility of not being able to duplicate and generate identical firmware builds.
Docker
Docker provides you with the ability to create a system-level image over which you have complete control. An image contains all the system components, tools, settings, etc. that you want. The images are not massive multi-gigabyte VM images. They’re much more portable. This is where the beauty of Docker comes in. You can simply share the image with everyone who needs to use the development environment. The Docker image can be run locally on Windows, Linux, and macOS easily alongside other applications. It also can be run remotely on a CI server. Docker is not dependent on the underlying OS being the same for every user, thus no need to reboot from one environment to another. It’s also lightweight, so it won’t hog resources like a virtual machine, and you still get flexibility. Every user can continue to develop within his or her customized development environment using their favorite tools and settings. Then, when it’s time to build and test, simply start up the Docker environment and build in Docker. Both environments live side by side on a single computer.
Docker is outstanding for projects with longer lifecycles. If tools change for newer development, but the legacy projects need to be supported in parallel, you can keep the older Docker images to support the older projects and create new images including the newer tools for new development. No more worries about a tool upgrade creating a chain reaction of upgrades or breaking something in the process. Each Docker image remains a snapshot in time, configured, and ready to go.
Conclusion
Thinking back on the countless hours tracking down differences in development environments to try to explain inconsistencies that showed up during testing and deployment. Or trying to resurrect an old computer to patch a project that could no longer be built on a new machine because the tools were outdated. Or trying to downgrade a tool due to an incompatibility. Or attempting to configure a brand new computer with a list of installation software to convert it into a development machine. Or trying to address an IEC-62304 Medical Device Software Lifecycle requirement to document and control development tools and environments. Docker can solve all of these problems.
It’s not often a piece of software that really impresses me. But this is one case where I can see the real advantages it offers, and have personal experiences where it would have been a huge time-saver in the past.
Let’s Work Together
And if you have questions about an embedded project you’re working on, Dojo Five can help you with all aspects of your devops for embedded journey! We are always happy to hear about cool projects or interesting problems to solve, so don’t hesitate to reach out at hello@dojofive.com or schedule a call here.
