Branch By Abstraction A [b] lesser-known source-control best practice[/b] I'vebeen pushing for a number of years is Branch by Abstraction. The suggestion is that you can convene large sets of developersin a single trunk and get then to continue to commit to a single placewithout having to spawn "short lived feature branches" when some largechange could mean that the build is going to be hosed for a number ofweeks while the team gets it right. Those branches just end uprunning and running.... ProvisosThere are some generalprovisos for the single as opposed to composite trunk design, thatcoincide with hard-core Agile development: [list][] You've broken your application into multiple components.[] Each component into a directory inside the trunk (possibly hierarchical).[] Each directory its own source self-contained and its own build (possibly hierarchical).[] You have a good set of unit tests and consider them important enough to illustrate snippets of example usage.[] Continuous Integration drives things, even for hundreds of components, that drops items into a Maven-like repository. [url=http://cruisecontrol.sourceforge.net/CruiseControl[/url]] has a nice [url=http://cruisecontrol.sourceforge.net/main/configxml.html#httpfile][/url] directive that with the [url=http://cruisecontrol.sourceforge.net/main/configxml.html#include.projects][/url] directive that allows you to set up the killer CI installation that isbranch-ready meaning you can run without a dedicated CI administrator.[] Your management are good at release planning.[*] Developers are in the habit of never breaking the build :-)[/list] Your trunk may look like:

trunk/ foo-components/ foo-api/ foo-beans/ foo-impl/ build.xml src/ java/ test/ cruisecontrol-config-snippet.xml remote-foo/ bar-services/ bar/ build.xml src/ java/ test/ cruisecontrol-config-snippet.xml bar-web-service/

[b] So back to the problem[/b].. What to do when (if) your team says they wantneed to shift from Hibernate to iBatis (hypothetical case). Therecould be thousands of classes that depend on Hibernate. Thearchitects might suggest that the build will be broken for weeks so aseparate branch is the best place for this change. Instead, letstry [b] Branch by Abstraction/b instead of the traditional "Branch by Source Control" ([url=http://digital-compulsion.blogspot.com/Stacy] Curl[/url] coined the name by the way - I'm trying to shame him into writing a better blog article than this one). The steps to living Branch By AbstractionWith your most responsible developers - [list=1][] Introduce an abstraction over the core bits of the big thing you're going to change.[] Update all the bits of code that were formerly using the thing directly to use it via the new abstraction.[] Make a second implementation of the abstraction, with unit tests that specifically test its core functionality.[] Update all the code from (2) to use the new implementation (still via the abstraction)[] Deprecate the first implementation (or skip to 6 if you don't want a respectful grace period).[] Delete the first implementation (its proven there is no need for you to go back).[] Remove the abstraction (if it is inelegant).[/list] Benefits[list][] Only a small team is even bothered by the change.[] You can go live at any stage - because the larger application works at all times.[] Management can be adaptive about scheduling.[] Avoids merge hell.[*] Introducing Abstraction helps increase understanding/modeling of piece - which is useful in itself.[/list] Of course, BBA [u] is not a panacea[/u].It is just a practice that developers/architects can often do it whenarchitects with less nerve are suggesting yet another long runningfeature branch. Architects should strive to do BBA instead of newfeature branches - Architects should not hope to reach a situationwhere they can declare at the outset that a new branch is the "onlyway" to achieve something.

A buddy last week was telling me of21 significant branches who's merge order was uncertain in his namelessclient. Sucks. He smiled wryly when I guessed Clearcase astheir SCM choice. Clearcase whether in dynamic, static or UCMmodes has no place in Agile development efforts. It is a selffulling prophesy that requires dozens of administrators a fewblack-belt merge-meisters and multiple branches and causes longdevelopment cycles, waterfall thinking and high staff turnover. The only thing worse that it is PVCS (who owns it now?). Anyone wanting a good tool for Agile development should belooking at [url=http://www.perforce.com/Perforce[/url]] (still my favorite cos Intellij works very well with it) or [url=http://subversion.tigris.org/Subversion[/url]]. Subversion will overtake Perforce one year soon I guess. When do you branch then?Ideally for release only. trunk/ releases/ rel-1.0/ rel-1.1/ rel-1.2.x/Youmay branch some days before release, then "production harden" thebranch on a staging box. You're not going to give permissions toall developers to that branch, just a couple who are ensuring its readyand handling later merges (one's or two's only if at all). Youbranch the release from trunk of course - given that CI proved thattrunk was at all times pretty solid.

As well as Stacy Curl, I'm hoping [url=http://www.martinfowler.com/Martin[/url]] writes an article on this important practice. He is better with words than me.

http://paulhammant.com/blog/branch_by_abstraction.html