We have a very big project that includes several applications that acts as the base for different clients.
Every client has its own personalization of the product, different milestones, different requirements and so on, and thus each project will evolve independently based upon its own needs.
The core of the project, is similar (but not equal) in every project and the organization is made so that there are teams that handle each client independently (but with communication among them as needed). So far, I've been unable to find any scheme that suits our needs, either by searching the internet or coming up with some brilliant idea 🙂
So far, we've been working by getting the product as a suit all needs, with specific branches for needed changes but, though the product has a good architecture, it's slowly becoming a big problem. Here are the main problems we face:
- Different milestones for each client: Which means each team has to produce versions as different times without the rest of the commits affecting the stability or their product.
- Different requirements, which may or may not affect the core of the system in some cases.
- Large teams (20+ team members)
- Handling bugs in the system: What do you do if a team finds a bug in his project that might affect other clients?
Note: We're talking about a project that has 10+M LOC.
Note: We're using Team Foundation System, Visual Studio 2008 and C# (mainly).
Any suggestions, sources or ideas about how to address the situation? Is there any model in the market that has a similar problem?
Best Answer
Actually, I would suggest that you do not need a branching model, but rather a complete comprehensive approach to deal with the multi-dimensional constraints with regard to the system without branching. In practice, I believe it will always be a problem to maintain multiple systems that have some commonalities but will evolve differently in branches, so it is better to turn everything into a single system that will evolve as a whole, but consists of different configurations. This may appear to be too simplistic, but there is extensive research in this area, with a lot of successful industrial applications.
The name for this approach is Software Product Lines or sometimes Product Line Engineering. From CMU SEI's Software Product Lines page:
The key idea is that every requirement, every milestone, every feature (a key term in this domain) is part of the complete system at the highest level. The actual systems deployed at various customers is essentially a collection of features. Each feature however is not just a physical component mashed into the system, it is defined as depending on or enabled by other features (so that by picking a feature, you may automatically include its dependencies, etc.)
Instead then of maintaining all these branches, you end up maintaining one system along with a set of customer-specific configurations.
It may be difficult or even impossible in practice to migrate to such an approach with a very large system, but even then it will be useful to investigate the approaches used in SPL in order to assess what approaches used there can at least be (partially) integrated in your work.
Some additional useful links: