Principles of Agile Version Control: From OOD to TBD

In this article, we discuss the principles of version control that help enable agile development. With an understanding of the principles of object-oriented design, as well as the principles of agile development, we can derive the principles of agile version control. We focus on the principles of object-oriented design (OOD) and how we can use them to derive corresponding version control principles for task-based development (TBD).

Symptoms of Poor Version Control

If agile and iterative development are always integrating, building and testing the software in very small increments, then how can we ever have stable baselines or codelines? How can we ever propagate fixes or enhancements from legacy releases to the current under-development release and make sure we aren't doing too much branching, merging and baselining? How can we make sure that the branching, merging and baselining that we are doing follows a simple, yet structured fashion that safeguards the integrity and reproducibility of the software without hindering productivity and development creativity?

Robert Martin desribes several symptoms of poor design in [1] that translate quite readily into symptoms of poor version control:

Rigidity/Inertia:

The software is difficult to integrate and deploy/upgrade because every update impacts, or is impacted by, dependencies upon other parts of the development, integration, or deployment environment

Fragility/Inconsistency:

Builds are easily “broken” because integrating new changes impacts other fixes/features/enhancements that are seemingly unrelated to the change that was just made, or changes keep disappearing/reappearing or are difficult to identify/reproduce

Immobility/Inactivity:

New fixes/features/enhancements take too long to develop because configurations and their updates take a long time to integrate/propagate or build & test.

Viscosity/Friction:

The “friction” of software process against the development flow of client-valued changes is too high because the process has an inappropriate degree of ceremony or control

Needless Complexity/Tedium :

Procedures and tasks are overly onerous and/or error-prone because of too many procedural roles/steps/artifacts, too fine-grained “micro” tracking/status-accounting, overly strict enforcement or rigid and inflexible workflow

Needless Repetition/Redundancy :

The version-control process exhibits excessive branching/merging, workspaces or baselining in order to copy the contents of files, changes and versions to maintain multiple views of the codebase.

Opacity/Incomprehensibility:

It is difficult to understand and disentangle the branching/merging and baselining schemes into a simple and transparent flow of changes for multiple tasks and features developed from multiple collaborating teams working on multiple projects from multiple locations for multiple customers

Why do these things happen? They may happen due to laziness or ignorance, or short-sightedness, or a host of other reasons. They happen because the practitioners involved haven't yet learned or appreciated the importance of sound version control principles and practices and haven't suffered the consequences of not following them. Or perhaps they have suffered the consequences but they don't understand why. So they blame it on the wrong thing and avoid doing the right things, such as trying to prevent change when they need to simply make change easier to do, or try to overcompensate for something “bad” that happened by going too far to the other extreme.

What's a seasoned veteran version-control practitioner to do? They do what they've always done! They use sound practices and judgment honed from years of experience to recognize these symptoms and their underlying problems, identify which principles have been violated, and apply the appropriate SCM patterns [2] for their particular context.

What are these practices and principles that help us to recognize and resolve these problems? Many of the practices come from what is commonly called change-based (or change-oriented) versioning and task-based development . The corresponding principles have much in common with the principles