【问题标题】:Branching a project for multiple customers为多个客户分支一个项目
【发布时间】:2018-01-12 23:52:08
【问题描述】:

我们有一个有多个客户的项目。假设应用程序名称是 Ali-Systems。 Foo公司会有Ali-Systems Foo,Bar公司会有Ali-Systems Bar等等。所有版本的结构几乎相同。但他们的逻辑是不同的。例如,所有版本都有一个BillIssue 方法,但其逻辑可能不同。无论是如何计算,甚至它们的 DB 模型之间的差异(我们使用的是 ASP.Net MVC Entity Framework)

据我了解,Microsoft 分类了一些分支策略,例如 Development Isolation(它使 下一个版本、实验或错误修复的并发开发),发布隔离(它启用并发 发布管理)等

我可以为此目的利用分支吗?如何?或者我应该为每个客户的项目创建单独的存储库?

注意:事实上,我想将一个项目的基础克隆到一些永远不会再次合并在一起的派生项目。但是我们必须能够为所有派生项目添加功能(可能在另一个分支的帮助下)

【问题讨论】:

  • 你使用的是 Git 还是 TFVC?
  • 我正在使用 tfs。 vs2015

标签: tfs version-control branching-and-merging


【解决方案1】:

微软有Visual Studio Team Foundation Server Branching and Merging Guide,可以用来选择分支结构。包括Main Only、开发隔离、功能隔离、发布隔离、服务和发布隔离、服务、修补程序、发布隔离...

在您的情况下,项目的核心是相似的,但是每个公司都有自己的产品个性化(逻辑/数据库模型),并且将来可能会独立发展。

使用一些分支结构,主要限制它成为解决错误和全局更改的维护噩梦。

例如,如果您要将更改从一家公司合并到另一家公司,这非常复杂,并且需要分别重新测试每个版本。此外,对于错误跟踪,一个团队将解决他们版本中的错误,而另一个团队将不得不从他们不完全理解的版本中合并该更改。

为了支持这样的开发场景,建议共享可扩展核心 和数据模型,可从上层自定义配置 应用层。这个核心应该被用作每个的基础 客户/公司特定的定制和单独维护 团队(针对每家公司)。它将包括一些管理并发症 因为多个项目经理可能需要来自同一个项目的资源 团队,但这是使架构保持一致、控制 整个过程并保持版本同步。

此外,如果一个人或团队需要在本地机器上跨多个公司工作,保持本地环境清洁的一种方法是Using multiple workspaces with Visual Studio

【讨论】:

  • 对像我这样的新手很好的解释 :) 但我希望必须有一种方法来分支这个场景而不会在合并中出现复杂的问题,至少不像你说的那样复杂。我错了吗?
猜你喜欢
  • 2010-11-28
  • 2014-11-27
  • 1970-01-01
  • 2010-12-06
  • 2013-11-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-10-13
相关资源
最近更新 更多