CODEWITHSUNDEEP
tfsversion-controlbranching-and-merging
ABS
ABS

Reputation: 2803

Branching a project for multiple customers

We have a project with multiple customers. Suppose application name is Ali-Systems. Foo company will have Ali-Systems Foo, Bar company will have Ali-Systems Bar and so on. All versions have almost same structure. But their logic are different. For example there's a BillIssue method for all versions, but its logic may be different. Either how to calculate or even the difference between their DB models(we are using ASP.Net MVC Entity Framework)

As I understand there is some branching strategies categorized by Microsoft like Development Isolation(which enables concurrent development of the next release, experimentation, or bug fixes), Release Isolation(which enables concurrent release management), etc.

Can I take advantages of Branching for this purpose and how? Or I should create separate repository for each customer's project?

NOTE : In fact I want to clone the base of a project to some derived projects which will never merge again together. But we must able to add features to all derived projects(probably with help of another branch)

Upvotes: 1

Views: 613

Answers (1)

PatrickLu-MSFT
PatrickLu-MSFT

Reputation: 51093

Microsoft has Visual Studio Team Foundation Server Branching and Merging Guide , that can be used to choose the branching structure. Including Main Only,Development isolation,Feature isolation,Release isolation,Servicing and Release isolation,Servicing, Hotfix, Release isolation...

In your case, the core of the project, is similar , but for each company has its own personalization of the product(logic / DB models ), and maybe will evolve independently in the future.

Using some branching structure, the main limitation it becomes a maintenance nightmare for solving bugs and global changes.

For example, if you want to merge changes from one company to another was very complex and it required retesting each version separately . Moreover, for bug tracking, one team will solve the bug in their version and another team will have to merge that change from the version they don't fully understand.

To support such development scenario suggest to share extensible core and data model which will be configurable from upper customizable application layers. This core should be used as the base for each customer/company specific customization and maintained by separate team(for each company). It will include some management complication because multiple project managers may need resources from the same team but it is a good way to make architecture consistent, control the whole process and keep versions in sync.

Besides ,if a person or team need to work across multiple companies in the local machine, one way to keep the local environment clean is Using multiple workspaces with Visual Studio

Upvotes: 1

Related Questions