from a "managing source code, customer versions & release management"
perspective, i'd suggest the following model.
Have a "core" codeline that holds everything that is common across all
customers.
Branch it once for each customer.
as you change the "core" code, merge is across to each customer branch.
You'd probably spend 1 person days a week merging core to 10 customer
codelines. Depending how active each customers codeline is. Use your CI
build server & Local running Nant to verify each merge. The key is to be
very careful & explicit in documenting a "How To" for merging between core &
all the branches. Remembering to update it as you add customers...etc.
OTOMH if i was using subversion for source control i'd setup the repository
like this:
{-} indicates subfolder
/TheProductName
-/trunk
--/Core <--put vs.net sln files in here
---/Project1 <--folder named same as a vs.net project, .proj file goes in
here with the .vb/.cs files too
---/Project2
--/CustomerA <---branched from "Core"
---/Project1
---/Project2
--/CustomerB <---branched from "Core"
---/Project1
---/Project2
---/Project3 <--this is specific to CustomerB
-/branches
--/Version 0.9
---/Core
----/Project1
----/Project2
--/CustomerA
----/Project1
---/Project2
---/CustomerB
----/Project1
----/Project2
----/Project3
--/Version 0.8
...etc
Your weekly merge cycle would look like:
Merge /branches/Version 0.8 into /branches/Version 0.9 <-- this puts the 0.8
bugfixes into Version 0.9
Merge /branches/Version 0.9 into trunk <-- this puts the 0.9 bugfixes into
the current codeline.
Merge trunk/Core into CustomerA
Merge trunk/Core into CustomerB
Merge trunk/Core into CustomerC
Merge trunk/Core into CustomerD
You'll need a build server to help automate the per-customer builds just to
save "hands-on" time...we've had good luck here with CruiseControl.Net. We
spent time setting it up so we can do "One Click" full customer release &
packaging of a build.
We have 5 or 6 "builds" available at any given point in time, it takes about
0.5-1 person day per month to manage it, tweak the configurations and setup
& configure new buidls as needed. We typically push new releases to
customers every 6 weeks.
You could also consider using compiler constants, so you have one codebase
but depending on the switches you pass to the compiler you get the customer
specific builds out of it. I feel this is harder to manage, code gets
"messier" and harder to read, the developer has to remember more... but
you'd end up with code line this:(air code)
Sub Button1_Click_Handler
#CustomerA
msgbox("hello Customer A")
#EndCustomerA
#CustomerB
msgbox("hello Customer B")
#EndCustomerB
End Sub
compiling with
vbc.exe /CustomerA would give you CustomerA's product.
the VS IDE has a UI to set these up.
If a specific customer has so many changes that you need fundamental product
changes, and it is overwhelming to manage the "diffs" from the "core"
codeline. Charge them a large one-time-fee for "code branching", and have a
completely separate codeline for them. Continue to bill them as normal for
each change request. The large fee makes the customer think hard about how
much they really want all the customizations, it also means that once they
pay it, they have committed to you. For example if you product costs $400,
i'd suggest charging around $2500 for a completely customized version, but
that should include allowing that customer to get the source code too.
(monthly zipfiles on a website should be enough).
Not sure if this is the info you are looking for, this post is more about
the day to day mechanics of juggling that many lines of code...were you
looking for other info about how to handle customers?, tracking bugs per
product line?..etc?
More info about the size of your product, what industry it targets and
general customer info would help us to give more help here. Do you sell to
large corporations with big budgets, or small mom & pop stores?
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Paul Cowan
Sent: Wednesday, September 05, 2007 10:45 AM
To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM
Subject: [ADVANCED-DOTNET] code stream versions
Hi,
We are running into an increasing problem with our product which I could
really do with some advice from someone of an experienced nature who has
possibly come across this problem before.
The problem is this:
We have a core product that 10 customers have bought. The problem is, each
one of these customers has made changes that customise the product to their
own need and has required meant that we have 10 branches of the code.
As we get more customers then this will mean more branches of the code.
Can anyone give me any advice of what is good practice for this type of
problem?
Thanks
Paul
[EMAIL PROTECTED]
_________________________________________________________________
100’s of Music vouchers to be won with MSN Music
https://www.musicmashup.co.uk
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
