How can I efficiently manage our product's code for multiple clients with separate customizations for each client?

Question

I just started a new job in a product-based company that allows client customizations. I work on product A.

Product A gets sold to client 1 and client 2 for example. So each client requests its own customizations. These customizations must be kept separate from the main stream features. However, new main stream features must be included in each of the clients' copies while reserving their own customizations.

Clients may request customizations from simple naming of fields or adding/removing grid or report columns to adding/deleting whole pages or modules.

We just started using SVN to manage our C#.net code.

My question is: from anyone's experience what is the best way to manage the code for all these requirements while reducing duplicate effort:

1. Main-stream product features for all clients.
2. Separate each client's customization and keep them for the client all along the client product's life time.

Branching may solve part of the problem, however main-stream features will not be included in clients' versions.

I hope this question is clear enough, and please explain your suggestion as clear as possible maybe with examples. Thanks

Answer 1

I'd recommend against keeping a forever-divergent branch per client. It will make any change painful, because there's likely to be some client's branch that gives merge conflicts.

From the examples you give, it sounds more like a simple matter of allowing more configuration. You could allow field names, columns, pages and modules to be configured via some sort of admin interface, and store the configuration for that on the client's end. Or, if you want to retain full control and don't want to build such a UI, store the configuration for each client on your end, and update it on their behalf.

Answer 2

In my company we have the same situation. Our solution:

• In SvN we have structure

  trunk - main product version branches - actual clients versions and future branch of new main versions

  • client 1 (v1, v2 etc)
  • client 2 (v1, v2 etc)
  • main version branches tags - release for main product version and client tags

When we develope main product we are commit to trunk (or future branches). When client request for new functionality - we develope this in client version branch. After release we made client tag (in tags) If client functionality is good and we decide do include it to main version, we merge his changes to trunk. Other side - if main functionality from trunk must be included to clients version - we made merge to client branches.

We have about 6 different client version. Actually we make merge manually, but soon we want to make batches to automatic this process

Answer 3

You may use

• Modular design (core+set of modules) and final product for customer will be combination (changeable set) of units, easy manageable with externals in repository (each customization produce new fork of upstream's unit): it's a mix of "vendor branches" + externals
• Monolite unified code, there each customer's customization collected in some configs (which you create automatically on release|build stage) and changes (based on this configs) are applied to common code on customer-side only
• Mix of previous methods - keep changes of every client in separate branch, sync branches with mainline development (dummy way, require strong merge-policy and accuracy, may require a lot of work on integration refactoring merge /google "Merge Hell", "Big Bang Merge"/ - but work seamless in stage of supporting changes in the middle of lifecycle)

---

I, personally, prefer Way 1 - it this case I know every second, which product each customer have (and haven't reconstruct it from log-history) and how this product evolved during the entire time of its lifecycle