Managing multiple code branches and deliveries

Question

I work for a small one-product one-customer company that is transitioning to a one-product, multiple-customer company. Even though we've had just one customer, we've had different projects with different delivery dates, but for each project we've been able to deliver the latest monthly release which we've kept in a separate code branch in case we've had to deliver bug fixes for that specific release.

Recently, we've acquired a number of new customers and a new problem has arisen: The head branch will typically solve (without breaking functionality) many different customer specific problems, and not all customers want all the changes, but would rather prefer to cherry-pick fixes and features.

Do you have any experience with that situation, and how to handle it practically without being overloaded by testing and work (our monthly release tests take about 3 days of computer time)? And version control wise, how do you manage (I guess cvs will finally have to go...)?

Answer 1

Its possible to use CVS in this situation (altough I would recommend you take a look at other options like SVN).

I worked on some similar projects. and what we did was having a Commom branch, for core features of the system and a "Customer" branch for each variation of the product, this way you can implement specific features and bugfixes of each client and still use the same changes in "commom" to all variations of the product.

This approach takes a lot of configuration management effort though (merging and building), so you might want to have a specific person to handle theses tasks.

EDIT:

Additionaly, you should (if don´t already) have a bug tracker system, in which you should document the client/branch you are working on.

Answer 2

The most simple solution is to cut the product into a core product and each feature into a plug-in. That way, every customer can cherry pick the features they want. But even this solution can quickly overwhelm a small company.

In reality, you usually are in a worse situation: You have a new feature which helps customer A and breaks something for customer B (say, customer B is not ready to modify their database and the new feature doesn't work without the change, so this in fact makes the new version unusable for customer B). If you were big, you could simply ignore customer B.

As it stands, you really need to find a way to convince your customers to move on. The most simple way is money: Tell them how much it will cost them to get a tailor made product and how much all them will save if you can find a solution that suits everyone. Invite your customers over, build a list of changes together and have everyone agree on the plan.

Also, you really must have automatic unit tests, so you can be 100% sure that the product which leaves the house today can't possible be worse than what you sold four weeks ago.

Even with the best version control system out there (for me, that would be git), you can't solve the fan-out you get if you can't get everyone pull into the same direction (except, of course, you can really split each customer into a plug-in).

Answer 3

We have a similar setup of one (fairly specialist) product and multiple (but only the order of hundreds) customers who all want their own pet feature.

As far as I can see you can either go down the 'off-the-shelf' route where your product is non-customer specific, and any features you add are for the good of the product (possibly at customers' request); or you go down the bespoke, consultancy route where every customer has their own unique version of the product.

If your customers all require basically the same product then you should go down the first route and that means all features go to all customers.

Hiding features is easy, maintaining multiple concurrent versions is a nightmare!

A solution which could work if your customers demand to cherry pick their features is to maintain branches for each of them and then very carefully copy relevant changes from your head branch.

This means that your commits need to be as atomic as possible - only fix exactly one issue - and that no changes should go directly into customer branches. But that approach is still very dangerous.

Answer 4

Only support the head/main trunk, unless there is a branch that has a bug fix/feature that is not present in the main line.

I know you said some customers do not want that, but I have seen the end result of the many branch support. You do not want that. It is a nightmare and will cripple your development, product and test teams.

Don't do it.

Be firm.