|
|
Re: Practice: Single Code Base: msg#00017
programming.extreme-programming.xp-explained2
|
Subject: |
Re: Practice: Single Code Base |
Brad Appleton wrote:
Hi Andrew!
Hi Brad,
snipped.
Thanks for the story (and the praise of the book :)
My pleasure, your help in SCM matters have served me (and others) very
well indeed over the 8 years I've been a developer. Starting fro CCIUG
days to now.
There is a trade off, the 'branch'ing still exists, albeit in code
rather than SCM, and so its just as possible to introduce bugs into one
version but not another. However, this is largely mitigated by because
we can build and test each of them at the same time from a single source
code base, rather than having to use the SCM tool's branching support.
Can you say more about what it means for the branching to be "in code
rather than SCM" ? I didnt entirely understand and want to learn more
about it.
Sure...
As we know, typically different versions of the same product branch at
SCM level, by Branch I mean a 'Variant' code base (project-oriented
branching), based upon the previous version.
Mainline for Product
0
|
1---1.1---.1.2--- 1.3 (no longer supported by company)
|
2---2.1 (only bug fixes and minor enhancements)
|
3 (Latest version of product - all singing all dancing best ever)
The problem I've seen in other projects, has been to do with having to
support 2.0 & 2.1 whilst at the same time work on the latest
version 3. Bugs fixed in 2.0 have to be merged into 2.1. If they
exist in 3.0, then they are merged there if possible, however, a lot of
the time, its not possible to merge the fixes between 2.x and 3.0
branches because the code has moved on so much and so the fix has to be
reimplemented.
Every now and a again we'll have one customer who wont upgrade to the
latest version of any of the offically supported versions (2.x), yet
still want and get support from the company - in these cases its a
business discussion as to whether we fix the issue the customer has, or
not and convince them to upgrade.
All this leads to the usual problems of fixes being applied to multiple
branch lines, and all of the associated work with those activities.
Having been burnt enough by this in the past I wanted a situation where
we could mitigate the need for duplicating the work, either through
having to merge the fixes/enhancements or simply having to re-implement
them afresh on each branch.
So how is this achievable when we still need to have the concept of
'branching' the product - as we need to support differing functionality
for the various releases?
The options I came up with are:
1) Branch within the SCM as above - nope
2) Branch at build time - using build parameters, #defines,
configuration scripts.
3) Runtime - using various patterns (Strategy, Command), config files
and behaviour registration techniques.
In our case, Runtime branching essentially uses a lot of build time
branchings support for creating/modifying any necessary config files -
although these could also be created/modified at runtime by the
products installation tool.
Within our application, there is a FeatureRegistry object that uses the
config files to determine what the product version is.
Within the apps startup code, features are registered with the
FeatureRegistry and provide a minimum product version that they are
allowed to be used with. This really is as simple as a product version
object and the features ID.
Then anywhere within the code that would make use of that feature,
checks the FeatureRegistry to see if the feature is enabled or not -
the FeatureRegistry simply checks the minimum version number against
what it thinks the product version is.
Using patterns like Strategy, Command, etc means we have a nice loosely
coupled design, which can change behaviour at runtime.
At present, there is no need to dynamically change the products version
number at runtime, but should we need to, then it wouldn't be to hard a
change to implement.
Its very much like how Java can change its look and feel at runtime, or
how a lot of products nowadays can have extra features enabled just by
buying a different licence key.
I believe (although I can't substantiate) the Quake game engine used a
simpler technique when they were developing Quake 2. They did start
with a branch, the continued with the Quake 1 code and extended it and
used config files (the Maps basically). This led to quicker release
times and the ability to give Quake 1 patches for bugs they fixed as
the went along.
HTH
Andrew
Yahoo! Groups Links
|
|
|
