Version Control Part 2: A Version is More than Just a Number

The benefits of version or source control include: history, branching/merging, and traceability.

Sometimes the smallest detail can have an astonishingly large impact … and a version number is such a small thing.

Keeping track of small details tends to be something of a strength of computer systems. Tiny details … even ones that don’t seem to matter. You know what I mean if you have ever used a technical term slightly incorrectly in the presence of a dev-ops engineer.

Let’s consider the benefits of a version control system: history, branching/merging, and traceability.

  • History – complete change history of every file.
    • Every change made by many different people over the years.
    • Changes = creation and deletion of files, edits to their contents.
    • Should include the author, date and written notes on the purpose of each change.
    • Enables going back to previous versions to help in root cause analysis for bugs
    • Crucial when needing to fix problems in older versions of software. (If the software is being actively worked on, almost everything can be considered an “older version” of the software.)
  • Branching/merging – allow team members to work concurrently, but even individuals working on their own can benefit from working on independent streams of changes.
    • “Branching” keeps multiple streams of work independent from each other and provides the tools necessary to merge the work back together. In software, this helps developers verify that changes on different branches do not conflict.
    • To that end, teams adopt a practice of branching for each feature or perhaps branching for each release, or both. We have even adopted the practice of creating branches for correcting specific defects – especially when the defect touches many different parts of the system.
  • Traceability – tracing every change made to the software and connecting it to project management and defect tracking software … annotating the changes with a message describing the purpose and intent of the change – helps with root cause analysis and other forensics.
    • the annotated history of the code aids understanding what it is doing and why it is so designed – this helps developers make correct and harmonious changes in accord with intended long-term design … note that the design itself is a high-value knowledge product that ought to be versioned and tracked
    • this is especially important for working with legacy (in some cases, ancient) code and
    • helps developers to estimate future work with accuracy

It is a poor workman who blames his tools … but tool is only useful if used …

There have been some amazingly expensive failures in IT – even where versioning systems are heavily used. Aviation, for example. The Airbus A380 suffered from an incompatible software issue … but not the avionics (a portmanteau: aviation electronics):

The Airbus issue of 2006 highlighted a problem many companies can have with software: what happens when one program doesn’t talk to another? In this case, the problem was caused by two versions of the same program – CATIA (CAD software that is used for design and assembly).

The Airbus A380, one of the world’s largest aircraft, was a major European undertaking. The problem arose because two organisations in the group – Dassault Aviation and a Hamburg factory – used two different versions of CATIA.

The German factory was using an out-of-date version of CATIA and Dassault used the latest version. Not surprising since Dassault developed CATIA.

When Airbus brought two halves of the aircraft together, the differences in the versions of the same software system meant that the wiring on one did not match the wiring in the other. The wiring was incompatible and had to be changed.

The problem was eventually fixed, but only at a cost that nobody seems to want to put an absolute figure on. But all agreed it cost a lot, and put the project back a year or more.

Moral of the story: even the best version control system on the planet is not going to fix using incompatible versions of tools on the same project.

Which is also why our devops engineers are soooo … picky!