Agile SCM - Patterns and Principles

This month, we go back to SCM patterns and consider the relationships between some of 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.

Principle List

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 ([1]) - 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 ([1]) - 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 ([1]) - 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 ([1]) - 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  ([1]) - 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 of the resulting avoidance of error is not always obvious.

Continuous Workspace Update ([2])  - PSP, IIP

As discussed in [2], this pattern works well together with private checkpoint, hence the same principles applying. "Little and often" seems like more work but it beats the alternatives!

Integration Build  ([1])  - CLIP, PLP, IPP, BLIP, CLFP, CFLIP, IIP

This pattern is a superset of Private Build. Collaboration/Flow Integration Principle is a dynamic expression of CLIP. Integration is all about collaboration, so CFLIP also applies,

Continuous Integration, Pre-Commit Validation and Post-Commit Notification ([2])  - CLIP, PLP, IPP, BLIP, CLFP, CFLIP, IIP

Continuous integration is the combination of Integration Build to ensure integrity with regular feedback to users which improves the flow of changes and evolution.

Again as discussed in [2], these are part and parcel of ensuring integrity (CLIP), and the net result is an increase in "rhythm" or frequency of correct checkins, thus an increase in flow.

Unit/Smoke/Regression Tests ([1]) - CLIP, BLIP

A pattern of principles occurring here! CLIP implies a number of patterns working together to ensure integrity - see the others where this occurs.

Codeline Policy ([1]) - CEP, CLFP, CLIP, CFLIP

This is a pattern of applying principles! Specifying the attributes of your codelines, and which principles apply to which level, defines the policy. Content Encapsulation

Active Development Line, Release Line and Mainline ([1]) - PLP, CLFP, CLIP, CLNP, CLBP, SPP, SHIP

Promoting changes between codelines in consistent chunks (PLP) keeps codelines as stable as possible, and yet provides for changes and evolution of those codelines as appropriate.

Conclusion

How well are the principles we derived holding up? Where are there overlaps with patterns? Where do principles add value, and where do they not? As you can see this is a work in progress and we look forward to feedback and suggestions!

We intend to revisit this article to consider some other commonly used patterns as well.

References

[1] Software Configuration Management Patterns: Effective Teamwork, Practical Integration; by Stephen Berczuk and Brad Appleton; Addison-Wesley, November 2002.

[2]  Codeline Merging and Locking: Continuous Update and Two-Phased Commits; by Brad Appleton, Steve Berczuk, Steve Konieczka, CM Journal, November 2003 (Vol. 2 No. 11)

[3] Agile Build Promotion: Navigating the Ocean of Promotion Notions; by Brad Appleton. Steve Berczuk; CM Journal, September 2004 (Vol. 3 No. 9).

[4] Continuous Staging: Scaling Continuous Integration to Multiple Component Teams; by Brad Appleton, Steve Berczuk, Steve Konieczka; CM Journal, March 2004 (Vol. 3 No. 3)

[5] Practical Perforce: Channeling the Flow of Change in Software Development Collaboration; by Laura Wingerd; O'Reilly & Associates, 2005. Chapter 7, "How Software Evolves" (available online)

[6] "Merge as You Go", Christopher Berarducci - Software Engineer, Handspring, Perforce User Conference 2003.

[7] Yesterday, my program worked. Today, it does not. Why? Andreas Zeller, http://www.infosun.fmi.uni-passau.de/st/papers/tr-99-01/esec99.pdf

[8] Delta Debugging, http://www.st.cs.uni-sb.de/dd/

[9] "The Illusion of Control", Agile SCM, http://www.cmcrossroads.com/content/view/6716/135/

Robert Cowham has been in software development for over 20 years in roles ranging from programming to project management. He continues his involvement in development projects but spends most of his time on SCM Consultancy and Training. He is the Chair of the Configuration Management Specialist Group of the British Computer Society, has a BSc in Computer Science from Edinburgh University and is a Chartered Engineer (CEng MBCS CITP). You can reach him by email at rc@vaccaperna.co.uk

 TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

Terri Gomez: SCM Engineer http://ncgr.org

Rather than a comment, I have a question. Under Task Level Commit you write: "The availability of Subversion covers those with limited budget". I have done some research on Subversion and learned that the BerkeleyDB has a tendency to lock up in Subversion. Because the use of the flat file system leaves you without integrity checking, that's not a viable option for us. Is my research still correct or has Subversion overcome the lock-up problem?

1

• report abuse
• vote down
• vote up

August 28, 2006
Votes: +0

Name

Comment

smaller | bigger

Subscribe via email (Registered users only)

Write the displayed characters

Add Comment