Pillars of Modern Embedded Development: Pillar 2 Managed Environments

Exactly the same environment for all builds, fast and verifiable.

Your build environment consists of the compiler, the linker, additional build scripts, and build tools-everything that is required from when you start your build, to when you produce a final, tested, releasable binary. These build environments are managed, traceable, and quickly stood up through container technologies. Below are 4 distinct benefits we find Pillar 2 offers for companies wanting to modernize their embedded processes using Managed Environments:

Painless Developer Onboarding

Let’s face it, starting a new role is hard. Not only are you trying to assimilate into a new organization with all of its ins, outs, culture, forms, paperwork, passwords, remote access, email and all things HR; as a developer, you also want to start coding! You want to get started contributing on your assigned projects right away.

Organizations with a standardized onboarding process experience 62% greater new hire productivity, along with 50% greater new hire retention. (Read the Harvard Business Review article here.) Same goes for having a centralized, constantly updated build environment through a tool such as EmbedOps. All developers on a given project are able to construct build environments with the correct dependencies, consistently across the team, as well as through to their production build environment.

Not only do managed environments save time onboarding new Team members, it’s likely that you’ll reduce that onboarding time from months to just days or even hours. Your Dev Team new hires will quickly feel like part of the community knowing all the important tools and software needed are in a centralized, easily accessible place. They can literally “hit the ground running.”-shortening the training process and making their first few days more productive.

Utilizing a managed environment fosters collaboration and creates stability, reliability, consistency and success in our software development projects. It further allows us to effectively manage and maintain the software environments throughout the development life cycle.

Reduced Inconsistencies Due to Differing Environments

Who hasn’t experienced this scenario: you and 2 other colleagues are working on a bug fix. However, all three of you are working independently from your own machine, and perhaps not even on the same version of the tool your all using. All of the sudden you realize nobody has a full version of the source code the bug was reported against. Oop-now what? You’re unable to fix it directly and must now go through an awkward, time consuming, and potentially expensive rebuild process to reconstruct some version of the code that matches what you are all trying to fix! What a colossal waste of time and resources.

What if you were using a containerized, managed environment for each stage of your project? (Complete with traceability and versioning-recall Pillar 1: One Source.) You’d know exactly which version to pull, identify others who worked on it, then troubleshoot and resolve the issue much more efficiently. Gone is the infamous quote: “Hey-it build fine and works on my system.” (See our blog on Troubleshooting). A managed environment ensures we can effectively address the complexities of development, testing, staging, and production in our embedded development projects.

Quick and Controlled Upgrades to Developer Tools

As developers, you use multiple development and project management tools to help keep your software development cycle on track and ensure the Team is able to deliver a product on time, on budget, and with no errors. Continuously changing software and development tools-paired with keeping pace with different versions and their compatibility is a major ongoing issue. However, by leveraging automated and managed environments, Teams can be rest assured they are working with the most recent versions. Managed environments are an excellent tool for building and maintaining a continuous integration (CI) pipeline for software build releases.

Tools like Docker allow you to package up an application (and its dependencies) into a container, which can then be run on any system that has Docker installed. This makes it easy to create a standardized environment for building and testing software, which is essential for maintaining consistent builds across different platforms and configurations. The result? Greater confidence in the build, fewer bugs, and the ability to quickly switch between different build environments.

Painless Production CI Releases

Using Docker images for your CI pipeline can also help streamline your development process. You can create separate images for each step in the build process, such as compiling, testing, and deploying, and then chain them together using a CI/CD tool like Bitbucket, GitLab, or GitHub. This allows automation of the entire build process, from source code to production deployment, and the ability to catch errors early on in the process. Docker also makes it easy to scale up your CI pipeline as your project grows, by spinning up additional containers as needed to handle more builds and tests. Overall, Docker images provide a reliable, flexible, and scalable foundation for your CI pipeline, making it easier to deliver high-quality software releases with greater efficiency and confidence. (Read our blog on using Docker.)

As more and more development teams embrace the benefits of Docker and CI/CD, this approach is becoming increasingly popular and is sure to play an important role in the future of software development.

In conclusion, I would be remiss to not briefly mention a distinction between a “managed build environment” that is merely about the build environment and setup as described above; and the infrastructure that supports distribution of builds to fielded units. The latter requires significant infrastructure that has to do with 1) how devices are designed such that they can support OTA or OTW (over-the-wire) updates and 2) how your CI/CD infrastructure can automatically distribute official release builds to devices in the field. Infrastructure deployment and management has its own unique challenges, and potentially requires a customer to obtain additional tools to maintain product revisions. This subsequently increases the cost to their development life cycle which we’ll discuss later in another Pillar.

Thoughts or questions?

Need help standardizing and streamlining your development environments or CI/CD methodology? Let us know-we’re here to help you on your journey to modernizing your embedded development processes. Come join the revolution. Next month, Pillar III: “Automated”

– Joe Schneider, Founder of Dojo Five –

Wanna stay in touch?

Subscribe to our newsletter! We’ll keep you apprised of the latest news at Dojo Five as well as interesting stories relative to the embedded firmware industry.