|
|
Re: Practice: Single Code Base: msg#00019
programming.extreme-programming.xp-explained2
|
Subject: |
Re: Practice: Single Code Base |
Brad Appleton wrote:
GREAT story of how you eliminated the need for version-branching by
deferring the feature-set selection logic to later binding time (run-time)!
Cheers
It sounds kind of like Doug Schmidt's "Service Configurator" pattern.
Yep, or 'Service Locator', Dependency Injection' or Mark Grand's
'Dynamic Linkage'
http://www.mindspring.com/~mgrand/pattern_synopses.htm#Dynamic%20Linkage
http://www.martinfowler.com/articles/injection.html#ServiceLocatorVsDependencyInjection
It
also seemed somewhat reminiscent of home some license-managers work to
lookup if a given feature is licensed for use by the current
user/installation (particularly when the software supports multiple
feature levels, say for eval/demo, home/personal-use, small-business,
and enterprise).
Yes exactly - its remarkably flexible, yet simple.
So are some of your your previous development CM problems now arising as
deployment (installation configuration) CM problems?
The previous problems included:
1) bugs not fixed in all release branches.
This does not happen.
2) Having to re-implement the bug fix due to the code base moving on
further in one release branch vs earlier ones.
This does not happen, the bug is fixed once for all runtime release
branches.
3) Likelihood of introducing new bugs as a result of fixing existing
bugs.
This has happened, yet because of TDD and acceptance tests, so far only
two minor bugs (that I know of) have made it into the wild in the time
we have used this approach.
Or are they new
problems instead? I know what kid of problems your solution avoided, Im
curious about your thoughts and experiences with the set of issues you
"traded-off" for instead, how you resolve them, and how/why you feel the
trade-off is worth it.
There is a new problem area introduced by working this way, mainly one
of a feature/or worst a part of it, being enabled in a release when it
should not be enabled. Like above, thanks to TDD and acceptance tests,
we have only had 3 occurrences of this (that I know of).
For me, the trade off's were mainly one of a perceived safety
of fixing bugs on separate release branches vs fixing the within the
single code base. I realised it was actually a a perception problem
first, in that it feels natural for most people to apply the 'it ain't
broken don't fix it' for when working with multiple release branches.
There's a lot of history of working this way and most people I know
tend to have it as a 'comfort zone' for developing in. By moving out
of that comfort zone, we naturally encounter resistance.
Secondly, from the XP context, I felt there was issue of 'DTSTTCPW' -
was it
simple to have late/dynamic binding vs static compile time binding
& multiple code branches.
Depending upon the teams experience of SCMs and OO Patterns, one is
simpler than the other. In the end, the shared dislike of our SCM tool
actually helped motivate the team to look at different approaches to
the 'usual' one of multiple branches.
Finally, the other practises of XP (test first and TDD) also helped to
reassure the team that at least we'd be able to verify the multiple
runtime release branches and their features, worked and were or were
not enabled etc.
There should be plenty of scope here for a new pattern in the next
edition of your SCM book ;-)
regards
Andrew
Yahoo! Groups Links
|
|
|
