Principles of Agile Version Control: From OOD to TBD

[article]

The Interface Segregration Principle for OOD states, “make fine-grained interfaces that are client-specific.” All consumers of a class should be partitioned into one or more client types and a separate abstract interface should be defined for each type of client the class must serve.

Interfaces are a form of abstraction and for version control we believe that translates into acceptance criteria for the users of a container and also a level of visibility of a container. For version control, interface segregation can be applied to changes, baselines, and codelines:

  • For changes, there are the times when they are private and still in-progress and then are subsequently ready to be promoted in visibility and used in progressively more public scopes of the enterprise.
  • For baselines, their contents do not change. What changes is the level of assurance we have as to their overall quality and readiness for production release/deployment. An in-progress change is just an initial, private and not yet promoted state of a configuration that may eventually be baselined and further promoted.
  • For codelines, their contents do change and evolve, sometimes to the point where it needs to be decided whether or not to branch a new codeline to support a parallel path of evolution.

All of these are really just forms of Visible IncrementalEvolution, when restating the general form of ISP in terms of version-control containers: Make fine grained acceptance-criteria that are client-specific.

Reuse, Release and Evolution Granularity

The OOD principles of reuse-release equivalence, common closure, and common reuse are all about the appropriate granularity of packages of classes. We wish to investigate the corresponding granularity of packages of evolution within a version control environment. We can consider the scope and granularity of a change, a baseline, a codeline, and beyond. In either case, both (re)use and release imply reuse by some consumer and releasing to some target consumer. Once again, the notion of abstractness in OOD translates to the level of visibility of versioned content that will play a key role.

In version control, the reuse of changes and versions occurs when we view or update (merge/modify) a version of one or more files in our workspace in order to develop, build, test and release our changes. The release of changes and versions occurs when we commit changes to a codeline, transfer changes between codelines, baseline a configuration, or promote a configuration to a new promotion-level. Based on this, we already know a few things about change granularity:

  • The granule of change is not an individual file/checkout, but is rather a single development task that holds changes we then commit to the codeline.
  • The granule of baselining and promotion is not an individual change but is, instead, the unit of integration for building and testing the component or product undergoing change on the codeline, which is the configuration.
  • The granule of progressive collaboration and evolution is the codeline

Not all of the above require principles. Furthermore it’s not apparent that each of these three OOD principles will translate to individual version control principles. Instead, we want to see if we can apply these three principles together as a group for each of changes, baselines, and codelines.

Package Coupling - Change-Flow

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Robert Cowham's picture Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!