Agile SCM - Relating Patterns to OOD, TBD and POB Principles

[article]
Summary:
The authors look at SCM patterns and consider the relationships between those patterns and object-oriented design principles of version-control for task-based development (TBD). They then move on to explore SCM principles for codelines, branching and promotion—project-oriented branching (POB).

We go back to SCM patterns and consider the relationships between them and the principles we have have expanded on in our previous two articles. Those articles considered how the principles of object-oriented design (OOD) applied principles of version-control for task-based development (TBD) with workspaces, changes, and baselines, and then moved on to derive principles for codelines, branching and promotion - project-oriented branching (POB).

Having proposed the principles, we would like to look at refactoring them where appropriate. First let us summarise the initial list of the relevant principles: [1]

    • ADP - Acyclic Dependencies Principle
    • BLIP - Baseline Integrity Principle
    • CBDP - Container-Based Dependency Principle
    • CEP - Content Encapsulation Principle
    • CFLIP - Collaboration/Flow Integration Principle
    • CHAP - Change Auditability Principle
    • CHIP - Change Identification Principle
    • CHTP - Change Transaction Principle
    • CLBP - Codeline Branching Principle
    • CLFP - Codeline Flow Principle
    • CLIP - Codeline Integrity Principle
    • CLNP - Codeline Nesting Principle
    • IDIP - Identification Insulation Principle
    • IDIP - Identification Insulation Principle
    • IIP - Incremental Integration Principle
    • IPP - Integration/Promotion Principle
    • PLP - Promotion Leveling Principle
    • PSP - Progressive-Synchronization Principle
    • SCP - Serial Commit Principle
    • SHIP - Stable History Principle
    • SPP - Stable Promotion Principle
    • STWP - Single-Threaded Workspace Principle

 

Private Workspace - STWP
Developer's work in their own workspace where they are in control of what is changing - their local check outs etc. Experienced developers tend to seek to stick to the Single-Threaded Workspace Principle (of course real life intervenes occasionally, and yet they tend to be more resistant to unnecessary interruptions or re-prioritisations). Multi-tasking seems to offer benefits and improved efficiency, and yet particularly with knowledge work, context switching rapidly uses up any gains. 

Workspace Update - IIP
How frequently should be update our workspace with changes from the repository? IIP suggests it be incrementally, and yet offers no more guidance than that in its current form. Laura Wingerd ([5]) makes a good case for bringing in changes one by one to make it easier to perform merges and to resolve conflicts. In addition, Christopher Berarducci [6] offers experience of how incremental changes brings benefits via automatic merging which exposes the problem in a similar way.

Task-Level Commit - SCP, IPP, CHIP, CHAP, CHTP
Task-Level Commit and the principles of CHIP, CHAP and CHTP are easily satisfied when using tools offering atomic change sets or the equivalent (the subject of a future article!). If you aren't using such a tool then you are missing out and should seek to rectify it quickly. The availability of Subversion covers those with limite budget...

Private Checkpoint - IIP, PLP
The willingness to take frequent checkpoints is often the sign of an experienced developer. It enables practices such as Delta Debugging [7] [8]. If you have saved 20 checkpoints in a several hour session then it is easy to find the bug you might have introduced in amongst the 19 good changes. If you took no private checkpoints, you sometimes spend as long finding the bug as you did making good changes with which it was mixed up. PLP seems to have some relevance here, and yet it is perhaps more related to branching patterns.

Private Build  - CLIP, PLP, IPP
Integrity as defined in CLIP is the most important principle behind Private Build. Far better usually (depending of course on the tools in use and how long such builds take) to discover problems early before checking in when the rest of the team to be affected. As discussed in "The Illusion of Control" [9], finding the right balance between the time taken to perform local builds and tests and the benefits

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!

Upcoming Events

May 04
May 04
May 04
Jun 01