Rediscovering the Obvious

…stumbling in the footsteps of greatness

Continuous Integration – When and why?

without comments

Earlier today, on Twitter
Me: Having issues with the positioning of continuous integration vs branching models lately. Absence of latent code pattern description, mostly.
Scott: What are the issues?
Me: Mostly around cross-team/large product situations where the need for selective feature disabling may arise from QA finding
Scott: Tell us more.
Me: This blog post

Continuous Integration

I’ve always viewed the concept of continuous integration (CI) as a very good thing. I relentlessly persue the reduction of batch sizes until it doesn’t make sense due to the transaction costs. I believe strongly in individual (pair?) developer discipline. I believe less strongly in a strong unit testing library and TDD, but view it as “usually a great thing”. I believe in flexible designs capable of handling varied changes in short durations. All the things that enable cross team CI are things I believe strongly in following, but I just don’t quite agree that it should be taken all the way.

On the kanbandev group on Yahoo! groups, there’s an incredible conversation going on between Brad Appleton and Bas Vodde between how large development teams can work using CI techniques, and the crux of the discussion briefly converged on the question: “Can you have large integrated teams without using a branching model?” For the purposes they are discussing, I would happily say “Yes”. However, I’m running into a different reason for branching: Providing options to management.

CI vs. Options

A branching model allows our developers to practice CI against a branch specific to their current Minimal Marketable Feature (MMF). Due to our frequent (average ~1.5 per week) releases to production, we have determined that we never want to have a partial MMF in production. Given a work in progress (WIP) limit of two MMF’s in dev and three MMF-equivalents [1] in SQA, we tend to do a production release whenever SQA approves one of their three slots. Our branching model allows us to do a good job testing the MMF on its branch because we update the branch from the main line on a regular basis and definitely before we push to the test environment. This allows a quick smoke test after we merge the branch back to main rather than a massive regression effort. This model allows our management to make a decision about individual MMF’s quality and determine which ones should be pulled into SQA (and thus for production). However, if an MMF happens to have poor quality, it is almost always found while the MMF is still on the branch, allowing its bugs to be worked and brought up to an appropriate quality while other MMF’s are able to continue. I think this is similar to the Release Train model, but rather than be on a time interval, it’s pull-based off of the SQA’s output queue.

Option source: Branching vs. Latent Code?

There are other ways of accomplishing the same goals. Specific features can be enabled or disabled through configuration properties at either build or runtime. This is _probably_ the better pattern for most situations. The situation I’m encountering with Inkubook is that many new featues are forced to touch huge swaths of the app (recent examples: Adding calendars (vertical), improving client performances (horizontal), modifying cloud usage (interface point)).  My question becomes: Are there effective latent code patterns for board, multi-tier changes? Given the nature of our application, I’d rather not have the code compiled into the client, even if it’s disabled by hiding a button or whatever… silverlight spy makes it all too easy to turn that button right back on. Disable things at the service layer? Do I write acceptance tests that ensure that other in-flight features are NOT accessible? That seems like waste. Seems better to know that the code just isn’t there… the costs aren’t bad if you’re good at branching, but at the same time, flipping off a property seems better.

Internal Consensus

As you can tell, I don’t really seem to have a full perspective on this yet. I’ll let you know when I decide, but for now I’ll recognize the value inherant in both approaches and wait for a reason to change my perspective.


[1] An “MMF-equivalent” is a nice tag to describe a batch of priority one bugs that have accumulated in the main line and are determined to be worth testing and releasing without waiting for the next MMF to be merged in and released.

Written by erwilleke

January 12th, 2009 at 11:53 am

Posted in Uncategorized

Leave a Reply