Principles of Agile Version Control: From Object-oriented Design to Project-oriented Branching


The Codeline Integrity Principle (CLIP)

Newly commited versions of a codeline must consistently be at least as usable as the previous version of the codeline. For many development shops, this is just a fancy way of saying to not break the build.  The basic tenet is to ensure that each change adds value to the codeline without compromising its quality or steady flow of progress.

The way that ISP applies to codelines is regarding integration milestones within a single codeline. This principle is so commonly known to many that it seems almost too obvious to bother saying, but it nonetheless needs to be said.

The Incremental Integration Principle (IIP)

Define frequent integration milestones that are client-valued. Many of us know the perils of big bang integration. It’s difficult to know just how frequently and incrementally we should integrate our work and make it visible to higher levels of the enterprise. The IIP gives us some general advice, but no specific recommendations. Perhaps the principles relating to evolution granularity can help us? When applying package cohesion principles to codelines, we arrived at the following?

The Collaboration/Flow Integration Principle (CFLIP)

The throughput of collaboration is the cumulative flow of integrated changes. The CFLIP says that collaboration is the source of value-generation (it constitutes both the source of change and reuse) and that the collaboration for a change is not finished until it is built+tested (intregrated) so as to be releasable (ready for reuse).

Principles of Branching & Merging

Principles of Branching & Merging

The Codeline Nesting Principle (CLNP)

Child codelines should merge and converge back to (and be shorter-lived than) their base/parent codeline.



The Progressive-Synchronization Principle (PSP)

Synchronizing change should flow in the direction of historical progress (from past to present, or from present to future): more conservative codelines should not sync-up with more progressive codelines; more progressive codelines should sync-up with more conservative codelines.



The Codeline Branching Principle (CLBP)

Create child branches for value-streams that cannot "go with the flow" of the parent.



The Stable Promotion Principle (SPP)

Changes and configurations should be promoted in the direction of increasing stability.



The Stable History Principle (SHIP)

A codeline should be as stable as it is "historical": The less evolved it is (and hence more mature/conservative), the more stable it must be.



For our interpretation of the LSP, another form of derivation in version control is when a new branch or codeline is branched from a particular point off of its parent codeline. The branchpoint is the baseline (r foundation configuration for the new branch. The new branch inherits all content from its parent codeline, while being allowed to evolve separately and, unless it is a permanent variant, usually diverges from its parent or base codeline for a limited period of time.  It then either promotes or propagates changes back to its parent at periodic intervals.

At the time it merges back into its parent, the CLIP then mandates that the integrity of the base/parent codeline must once again be maintained. Regardless of whether the child branch is for maintenance purposes or for new development, the parent codeline should be longer-lived than the child. Also, the child should merge back to its parent, possibly multiple times as well as at completion.

The Codeline Nesting Principle (CLNP)

Child codelines should merge and converge back to, and be shorter-lived than, their base/parent codelines. The CLNP actually conveys fundamental advice about the branching structure of a component or product. It says to use a simple, recursive hierarchical structure, similar to the preferred control-flow structure (and indentation format) of statements in a computer program. The CLNP suggests avoiding the continual cascading/staircase style of branching and instead points us in the direction of theMainline pattern for organizing our branching structures using nested synchronization. [2], [10]

 The CLNP also seems to share a great deal in common with the portion of Laura Wingerd's Base-Codeline Protocol that says that changes should always flow from child codelines to their base/parent codelines. The other half of the base-codeline protocol addresses the main difference between the two scenarios above: changes flow from parent to child only when the child is for new development and not when it is for legacy maintenance. This is necessary to maintain the integrity of both codelines while also preserving the relationship between them. The CLNP doesn't go quite this far, but perhaps one of our later principles will. If changes should always flow from child-codelines to their parent-codelines (CLNP), then when, if ever, should changes flow in the reverse direction (from parent to child)? In general, we have three basic kinds of codelines and change-flow:

·       New development and change promotion: Development lines are used to create new functionality (value-adding changes). Such changes are promoted when they are merged from a workspace are committed to a codeline.

·       Legacy maintenance and change propagation: Maintenance lines are used to make fixes and enhancements (value-preserving changes) to help stabilize and maintain an existing release of the software. Such changes are merged  from a maintenance codeline where they were already integrated and tested, to a subsequent codeline that will also benefit from the fix or enhancement.

·       Mainstream integration and synchronization: A mainstream integration codeline is for integrating the latest and greatest stable state of progress. New development changes are synchronized (or updated or rebaselined/ rebased) from their main codeline by merging the current configuration of the parent to the workspace/branch containing the new development change. 

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.