When talking about adopting agile development, continuous integration, continuous delivery and DevOps practices, having a proper version control system and setting up the right workflow is one of the basic things to tackle. It takes you through most parts of the Dev-Test-Operation building blocks — code, build, test and release. Researches of SW R&D teams show significant improvements reducing time to market for new features when proper source control practices are implemented [1].

Today the most popular version control system for agile teams is Git so this blog post will be focused around a specific Git workflow, that suits embedded software development.

Git-Flow

image taken from — http://nvie.com/posts/a-successful-git-branching-model/

For us at Jumper, after trying a few git workflows, we’ve decided to work with Git-Flow as proposed by Vincent Driessen (If you are not familiar with Git-Flow I encourage to read about it).

In a nutshell Git-Flow is designed largely around the release and advocates to splitting your work between two main branches:

Master : What is currently on production — the stable branch.

Develop : The next set of features we are working on — the bleeding branch.

Git-Flow also talks about few supporting branches and how everything connects together.

We find this workflow, though it might seem a bit cumbersome, to be very useful for embedded software projects. On Web or Mobile application, you might not need one or more of the development, release and master branches. However, embedded software can not be deployed all the time as physical devices are not always ready for update. Another reason is that software updates might need to be certified. We find the master, release and development branches to be of a necessity when you are not deploying all the time.

Think about what happens when you find a bug in production but the time from a ready deployable package into actual firmware update on the field is days or weeks. During this time your development team is working on the next set of features. If you merge directly into master, but you’re not ready to release all your features yet and a bug is found in production — you’re stuck having to go back to the tag that’s in production, branching that, testing, releasing the branch, and then merging in. With a develop branch this isn’t an issue. New features are on develop. Hotfixes are branched off master, and then merged into master and develop when finished.

Can I get the same benefits with tags?

Git-Flow provides a clear separation of concerns for new feature development, ongoing general maintenance, each release window, and emergency maintenance. Master is the holiest of holies, and must remain in a pure, working, deliverable state at all times. Sure, we could technically achieve the same thing by tagging the releasable commits, but the separate branches provide a clear distinction, and that is beyond invaluable in embedded software development.

It’s also useful to see at a glance what you’ve released, what you’re about to release, and what features are yet to be included in any release.

Embedded Software Development Constraints

Developing software for embedded systems introduces constraints that have an affect on your Git and software development workflow. We think that the three ones below are the common ones for most embedded systems projects:

Hardware Configuration — During a project life time you need to support different hardware configurations, meaning you need to maintain different software versions. Certification Time — Certification process which is a must for medical, automotive, industrial, etc., introduce long test cycles before a release, meaning merging to master is postponed. Automated Testing — The physical device makes hooking up automated testing process to a Git workflow cumbersome (learn these five steps for moving from manual to automated testing in embedded).

All three constraints are related to the Git workflow you choose, but the third one also require testing framework that will allow you to run automated testing for embedded software products (check about test automation with Segger tools).