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 to 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 attempt 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 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 and 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.

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. Or it can be run remotely on a CI server. Docker is not dependent on the underlying OS being the same for every user. No rebooting from one environment to another. It’s also lightweight, so it won’t hog resources like a virtual machine.

You still get flexibility. Every user can continue to develop within his or her customized development environment using those 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

I think back on the countless hours tracking down differences in development environments to try and 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 never updated by the developers. Or trying to downgrade a tool due to an incompatibility. Or attempting to configure a brand new computer will 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.

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 and chat with us on LinkedIn or through email!

Posted in Development Processes