Planet SCM

Almost a year ago I posted an entry on the "5 C's of Agile SCM Codelines". This time I'm posting on the 5 R's of Agile SCM Baselines. I think these are as follows (note that most of these are not unique to Agile/Lean):

• Repeatable -- The steps to create the corresponding Build (Configuration) from its sources should be repeatable: for any baselined configuration, I should be able to build it the same way, over and over again.
  


• Reproducible -- The corresponding Build (Configuration) should be reproducible: for any baselined configuration, I should be able to reproduce it whenever desired.
  


• Reportable -- The corresponding Build (Configuration) should be reportable: for any baselined configuration, I should be able to report all needed details about its content: what files & versions are in it, which changes/requests are in it, who made which change to what (& when), how it was built and with what tools & options, etc.


• Releasable -- The corresponding Build (Configuration) should be releasable: if I have "baselined" it, then almost by definition, it means it should be of 'releasable quality' to the next downstream consumer. (This implies it should be correct + consistent + complete to the extent agreed upon with the its stakeholders.)


• Repairable -- The corresponding Build (Configuration) should be readily repairable: if, for any reason, it is discovered to have some kind of problem, then I must be able to readily repair it either by retracting it and replacing it with it's predecessor, and/or by removing/repairing the offending content and releasing it as a new (corrected) baseline.

I use the term "reportable" instead of "traceable" here for two reasons: 1) 'traceable' doesn't begin with 'R', and 2) 'traceable' brings to mind many negative associations with manual tracing, rather than simply providing the necessary transparency and ability to trace (without necessarily implying doing all that tracing, much less doing it all manually).

Note also that "repairable" may not imply that the cost of repair is low. Ideally, the repair can be done as quickly as possible by the development organization, but getting it to the consumer(s) may be both costly and time-consuming. So, rather than "low cost", being "repairable" speaks more to maintainability, and the ability to quickly understand the system and what must be done to repair it. We want to repair it with minimal interruption of flow, and with a minimum amount of overhead.

Why is any of that particularly "agile"? Most of it isn't, but the 'take' on reportability certainly is, and the notion of "releasable" may seem agile to those who feel the codeline should (ideally) be in a readily releasable state. CMers would say that "releasability" was always part of what a baseline requires (and they'd be right).

What do you think? Did I miss any other important R's? Or should something else be used instead? Would an additional R-word or two not listed above help differentiate between "Agile" CM versus more traditional CM?

Here are all the other R-words I considered:

Recoverable Reliable Reversible Retractable Retainable Realizable Relocatable Remediable Repealable Replicable Revocable Relapsable Rebuildable Recapturable Reconfigurable Reconstitutable Reconstructible Recordable Recyclable Referable Retrievable Reusable Restorable Renewable Replaceable Representable Respectable Responsible Removable Reachable Readable Receivable Reclaimable Recognizable Recommendable Reconcilable Recreatable Remissible Rectifiable Recuperable Redeemable Reducible

If anyone cares, I looked it up at Dictionary.com searching for "r*ble"

In an earlier blog-entry reviewing the book Code Craft, I mentioned the classic paper by Peter Miller entitled "Recursive Make Considered Harmful" ...

Anyway, I recently ran across a bunch of webpages that examined or revisited the issue. I thought several of them were worth sharing, so here they are:

• Recursive versus Non-recursive Makefile architectures benchmark
• Recursive Make isn't all that bad
• "Recursive Make Considered Harmful" Revisited
• Recursive Make Reloaded
• Implementing non-recursive make
• Non-recursive make for Linux kernel
• Non-recursive Automake
• Makepp manual pages on recursive make in legacy makefiles and problems associated with recursive makes

The current issue of Communications of the ACM is focused on Software Product-Lines for software engineering. It has a number of interesting articles on software product-lines and product-families for large-scale reuse.

It even has a few articles related to CM of product-lines, particularly change-management and variability-management:

• Feature-oriented variability management in product line engineering
  Jaejoon Lee, Dirk Muthig


• Multi-level customization in application engineering
  Krzysztof Czarnecki, Michal Antkiewicz, Chang Hwan Peter Kim


• Product management for software product lines: an unsolved problem?
  Andreas Helferich, Klaus Schmid, Georg Herzwurm


• Change management patterns in software product lines
  Kannan Mohan, Balasubramaniam Ramesh

I received a copy of the book The Buildmeister's Guide: How to design and implement the right software build and release process for your environment, by Kevin A. Lee, who runs www.buildmeister.com (the book is also available on Amazon.com).

I really liked Kevin's earlier book on ClearCase, Ant and CruiseControl: The Java Developer's Guide to Accelerating and Automating the Build Process. Even though it was specific to ClearCase it had a lot of really good information in general about build/release process automation. The Buildmeister's Guide "builds" on that (no pun intended) and covers build automation tools (such as CruiseControl and BuildForge) as well as Version Control in general (including tool selection and branching/merging policies). It also covers more than just Java, and has sections on other language & environment factors like .NET and C++.

All in all, it looks like a very good, and short (~110 pages) guide for beginning and intermediate build-meisters to learn a whole lot more about effective practices, resources and tools for software building and releasing.

David Anderson writes about the recent Agile2006 conference in his blog-entry Thoughts for Agile2006:

Scaling Agile. The BIG issue for this year is scaling agile across a whole organization. I see this as having three parts - program or multi-project management and the rollup of schedules and resource plans to a Director or VP level; architecture and enterprise level modeling of a domain and data center; and finally configuration management including build, integration, branch and merge strategies, and work-in-progress batching and related communication.

Ive been dealing with this topic a LOT lately in my own organization as part of efforts to spread amd adapt Agile methods across a large distributed enterprise working with large systems and teams. Ive been researching and collecting lots of resources, including some earlier blog-entries on Agile CMMI and Dancing Elephants and Agile Adoption across the industry.

My perceptions of where the "seams" of the enterprise are that are hardest to introduce Agility into are the close collaboration and alignment required across organizational (lifecycle discipline) boundaries and geographic boundaries (and I find the former to be more difficult to surmount than the latter.)

If I try to categorize them as different areas or aspects that each require the ability to be agile, I come up with something like:

• Process - Adapting Agile to the Organization (making processes responsive to change)


• Product - Agile Systems Engineering/Architecture (making the requirements & architecture be responsive to change)


• Project - Agile Program Management & Governance (making the project be responsive to change)


• People - Distributed Agile Development (collaborating across multiple sites, teams, and timezones)


• Organization - Agile Metrics/Reporting, Governance, and Organizational Design
  


• Environment - Agile CM, deployment, operation/support, etc.

I'll be blogging separately with lists of resources of found for several of the above.