This project has moved and is read-only. For the latest updates, please go here.

Branch Strategy Multiple Clients

Sep 29, 2011 at 3:55 PM

Hello,

I am sorry but i am quite new with branching in source codes. We are a 8 people team working in SPW (reaaaaally old code) in which versions are not supported since all development is made in the same server. And now we are moving to .NET.... scary :D

Anyway, we have developed 5 products for the last 15 years and have about some clients for one or more products.

Our software is about logistics and each client needs a customization. The software is standard and is evolving with the time...

After some reading in Internet I have decided to have a MAIN/DEV branch of each product. Then each client will have its own branch (dev & release) from the release they bought. Those branches are used for testing since each client has its own customization...

 

Something like

+ DEV

+ MAIN

+ Release 1

+ Client 1 Release

+ Client 1 Dev

+ Client 2 Release

+ Client 2 Dev

+ Release 2

+ Client 3 Release

...

 

But i am not sure about this scenario. The thing is how can i upgrade here a client to a new release? Product release branches are used for some way of Service Pack

Sorry if i said something really wrong.

- Do you think is this strategy acceptable? Then how to upgrade a client?

- If not, what is the better solution?

 

Thanks for your time!

Nov 25, 2011 at 5:19 PM

What is SPW? Does it involve source code?

Did you say that you have never before had versions because your previous platform did not support that? And you and your team are new to source code branching and merging?

Based on this, I recommend you try something VERY simply to start.  Your are proposing two substantial changes at one time. This dramatially increases the risk that you will be overwhelmed and fail during the change. The first change is moving from an older technology platform to a newer one.  That is huge. It will require training and time. Your best bet to success here is to hire someone experienced to mentor your team.  And set expectations about how long you must work to gain the experience to be good at this new technology.  The second change is going from a versioning strategy of "Only one version" to "Lots of versions: a standard one and one per customer"  This would scare anyone.

I have seen the pattern you describe before, and I have seen companies abandon it because it is not economically sustainable.  Once you agree to customize the source code for each client, it will vary from your standard offering.   The first problem you will face is that this is expensive. Instead of enjoying the benefits of a shared product, and distributing the customization costs over several clients, you are now doing customized software for each client.  That raises their costs and if they are price-sensitive, it will make it impractical for you to continue that business. If they have deep pockets, then maybe it will work. See http://www.p2energysolutions.com/excalibur/excalibur-quarterly-newsletter/2010/spring/the-case-for-standard-software to learn more about this pattern.

The second challenge is seen in response to your question "... how can i upgrade here a client to a new release?"  If each client has a unique source-code base, then you are asking "How can I bring all the features of Release 2 to clients who have uniquely customized versions of Release 1?"  I can envision a branching plan that might work, but I would not want to implement it unless I had a team of developers and architects experienced in branching and a compelling business case that overrides the economic objections I raised in the previous paragraph. Here is the problem. If you develop a standard product, and upgrade it to release 2, let's assume you made some really substantial changes to the source code. Now, because you have a version of code for every client, you must manually merge the standard release 2 into each client's release 1 product. Each of these merges is labor-intensive. The more customizations you do for the client, the more work it will be.  This can be done, but it requires a conceptual understanding of branches and the tools that will not be present for those new to this. And if the changes customized for the client are minor, then it should be easy enough to make them configuration options and stick with one standard product.

Finally, this approach of customizing source code, without careful architectural decoupling, is just not scalable. If you aggressively sell several more customers, then you must add several more developers to support them.  If you take the approach I suggest below, you will not need to do this.

I think that using source code branching is the wrong way to try to solve this.

IMHO, the most scalable and economical approach is to have one standard product and avoid customizing the source code at all costs. If customers need variation in the product, then I recommend you redesign the single, standard product, to have configurability options that enable the range of variation your clients require, but all work within the context of a single product.  If that is not enough, then you can introduce loosely coupled extension points. Yes, these may involve "custom source code" but it is within a loosely coupled framework that is build to a standard interface. The economics is discussed in the link I provided above.

If you choose to use the most complex approach, of truly branching the entire source code of the product for every customer,  TFS is versatile enough to support it. And TFS 2010 has the tools to make it as easy as possible. But I recommend you first make the transition to the new platform and get comfortable with it to support a single product and version. You should consider something like the Basic or Standard branching plans described in the guidance. Once you are comfortable with the tools and platform, and doing simple branching and merging, you could explore the three levels of variation support described in the article:

  1. configuration
  2. extension
  3. customization of source

TFS 2010 will support the third option, but I would recommend against your team trying it at this particular time. And when you do, you may want to ask for advice in forums that cover architecture. Because the concept of supporting multiple customers with a software product that is adaptable to their variations is first an architectural question. Once you have a sound architecture, the branching will be easier to figure out. But I suspect you will not adopt an architecture that requires you to give each customer an entirely independent branch of the standard product.

 

 

 

 

Feb 9, 2012 at 3:40 PM

Hello,

I never had the time to thank you for your time in this reply. I read it a long time ogo, and I decided to follow your instrunctions. we did it very simple and it was hard to get everybody used to the source code control. There is no integration or migration or update of releases between clientes, for the moment we keep each client as an independent branch and there is no relases, updating is considering a project itself.

We are thinking a new architecture in which customizations are made by configuration, but it is going to be a whole new release in which we are gonna break backwards compatibility. As you said each project seemed complex enough so I decided to follow your advice and try to make it as simple as I could.

Thanks again for your time.

Feb 9, 2012 at 9:53 PM
You are most welcome.
David Allen

Sent from my iPhone

On Feb 9, 2012, at 9:40 AM, descalada <notifications@codeplex.com> wrote:

From: descalada

Hello,

I never had the time to thank you for your time in this reply. I read it a long time ogo, and I decided to follow your instrunctions. we did it very simple and it was hard to get everybody used to the source code control. There is no integration or migration or update of releases between clientes, for the moment we keep each client as an independent branch and there is no relases, updating is considering a project itself.

We are thinking a new architecture in which customizations are made by configuration, but it is going to be a whole new release in which we are gonna break backwards compatibility. As you said each project seemed complex enough so I decided to follow your advice and try to make it as simple as I could.

Thanks again for your time.