Hardware Version Control Workflow

How a new workflow can help you iterate your way to great products.

In this post, we describe how the hardware version control workflow can support the ‘user-centric & iterative’ hardware development process, as described by Bolt in our previous post.

Bolt’s process entails fast-paced iteration based on user feedback and insights gained during engineering to ensure that you develop something to solve a real need in the right way.
User-centric & iterative hardware development builds upon a mindset that most software startups regard as best practice. 

hardware-version-control

Introducing the Hardware Version Control Workflow:

The hardware development process incorporates every phase from ideating your initial idea to getting the first batch of a manufacturing line.

At its core is the part where you design and engineer your product, and it is during this phase where your workflow of organizing and sharing your work can really help to make iterations fast and secure.

And just as with the whole overall hardware development process, your workflow can also greatly benefit from incorporating aspects of how software teams or communities work together effectively.

The Hardware Version Control workflow is built on three core ideas:

  1. Distribute information
  2. Develop in parallel
  3. Synchronize continuously

The practical implementation of these ideas is supported by a distributed version control system. Version control technology also comes from the world of software development.

Distributed information:

distributed-information

Each member of the development team or community has access to the concurrent version of the project, its complete history, and relevant context.

– Why?
You want to have distributed information because it increases the speed of development, reduces the chance of mistakes, and empowers people to work more independently.
When everyone has access to the concurrent state, you lower the chance of errors such as building upon the wrong version of a file.

Access to your project’s complete history with annotations alongside each committed revision enables you to retrace steps and decisions made by yourself and team members. No more reinventing the wheel for decisions that have already been made.

Secondly, by distributing information people can work more independently and encounter fewer roadblocks (e.g., your internet is down, or you can’t reach your team member to ask if they have already made the improvements you are waiting on).

– Practical Application
Practically, this means you’ll have your complete project accessible on a central cloud instance, and have local copies of the entire project on your team members local computers.

Next to the concurrent version of your files, all your project’s historical revisions are stored, and each revision is annotated with a message that describes the changes. Alongside the source files of any part, you store relevant decisions, values, and design documentation.

Parallel Development:

parallel-development

Development happens in parallel for each sub-assembly (a group of components that make up an independent part of your project), while there is always one clear, stable concurrent version; a single ‘source of truth.’

– Why?
Parallel development means that everyone knows what and where the latest stable revision of your project is while being able to carry out development and experiments independently and securely.

Maintaining separate parallel tracks of development also groups the committed changes for each part of your project, which keeps your history organized.

– Practical Application
Version control technology enables you to integrate parallel development into your workflow by using the concept of ‘branching’. A branch is essentially a parallel track for making development changes.

Branches enable you to have multiple states of your project simultaneously, whilst the version control system enables you to switch between those states. Think of branches as railroad tracks that divert but can merge again at a later point in time.

Your project contains a branch called ‘Master’ that, in turn, contains the latest completed and validated revision of your product.For each assembly that is currently under development, you’ll create a branch, which will contain the changes you make until you reach the next stable, validated version of that assembly.

Once completed, the validated version of the assembly branch is merged (like the railroad tracks) into the ‘Master branch’ and becomes the stable version. What validation means, in this case, depends on your project and the specific assembly; it can be something like a second opinion from a team member or extensive field testing.

This is really the only hard rule of the hardware version control workflow: everything in the ‘Master branch’ is always, always the accepted, reviewed set of sub-assemblies that fit together into the latest version of the product.
This means you can always safely create new branches off of the `Master branch` to base new iterations upon. It is the ‘single source of truth,’ the default state of your project.

Continuous Synchronization:

Illustration-process-(work-files-commit-sync)

Every substantial change is committed to the history of the project and synchronized with the development team or community.

– Why?
Committing revisions continuously creates a logical stream of changes that you can always revert to. It gives you the confidence to make quick iterations.

Synchronizing your work with a central instance and your team members remove the risk of losing work and ensures that despite dealing with distributed information everyone stays up to date.

– Practical Application
As soon as you have completed a meaningful change you should commit it to the project’s history. A meaningful change doesn’t mean a completely new iteration; maybe you only added a small screw hole to the 3D model of an enclosure you have designed.

You then synchronize your committed revision to the central instance so your whole team has access to the latest work in progress. Similarly, you continuously get changes from other project members to ensure you always have access to the latest work.

To keep this stream of information useful you accompany each committed revision with a message that summarizes what changes were made and describes important context or decisions.

These ‘commit messages’ are stored with the changes you make, enabling you to easily retrace your steps and understand the reasoning for changes.

Summary:

A good workflow ensures a fast, iterative process, which results in better products so that you can make a bigger impact with your work.

With the hardware version control workflow:

  • Your work is supported by a version control system.
  • There is a central instance and distributed copies of your project with its complete revision history.
  • Parallel Development happens in branches for each subassembly of the project.
  • The ‘Master branch’ contains all the completed and validated changes to your product.
  • All changes are committed the history, annotated with a message, and synchronized continuously.

Today, most hardware development teams and communities are still using general purpose tools like Dropbox/Google Drive, or complex legacy PDM systems that originated in a top-down, heavy managed environment that followed a linear development model.

We have workarounds but not a workflow.

Yet it is increasingly cheaper and easier to develop high-quality hardware due to digital manufacturing and affordable electronics. And these changes make an iterative process possible, increasing our ability to innovate.

Hardware development is changing, so should the way we work together.

If you would like to learn more, we have additional information on the hardware version control workflow at help.wevolver.com, including how naming conventions can help you keep the peace of mind when managing files.