2

我们正在寻找有关 TFS 和多个应用程序（一些是 COTS；一些是内部开发）的分支和合并的指导，并与多个开发团队合作。请注意，我们目前使用每月发布窗口，但将每季度发布一次。我们还需要能够支持 eFixe 和非发布开发工作（即：必须在窗口外实施的监管变更）。根据目前的研究，我们正在集中精力研究以下两个选项：

选项 1) 每个主要应用程序的发布分支，其中每个应用程序将具有 MAIN、RELEASE 和 PRODUCTION 分支（生产分支将支持 eFix 分支，该分支将支持 eFix 和非周期更改）。

选项 2) 整个组织的发布分支 - MAIN、RELEASE 和 PRODUCTION 分支将包含所有应用程序。

4

1 回答 1

3

这里有一些有用的分支建议：

Visual Studio Team Foundation Server 分支和合并指南

WRT到你的问题我的观点是

选项 1) 单独的应用程序发布分支

这是如果您的应用程序之间没有太多的依赖关系（如果有的话）。

优点：

  • 构建会更快
  • 为 Cherry 挑选部署组件提供更大的灵活性
  • 更适合持续集成构建，因为您可以很少且经常构建和部署
  • 根据您的质量质量门签署和锁定个别应用程序
  • 更容易重新部署关键修复
  • 合并更小，可能更频繁

缺点：

  • 维护构建/部署脚本的可能管理开销
  • 如果存在应用程序依赖关系可能会在挑选组件时引入风险
  • 需要可靠的部署框架来维护程序集版本和标签。
  • 部署时会涉及多个部署资产资源（而不是1个部署包）

选项 2) 所有应用程序发布分支

优点：

  • 更容易随时识别所有应用的版本，
  • 可以使用 Teardown 和完全部署进行部署，
  • 更少的构建和部署脚本需要管理
  • 减少部署资产资源来管理。
  • 更容易跟踪/可视化发布级别的合并/变更集

缺点：

  • 构建可能需要更长的时间
  • 如果应用程序不适合用途或在代码冻结/注销后包含错误，则发布灵活性会降低
  • 更难挑选部署组件
  • 生产关键修复可能需要更长的时间才能重建和部署
  • 回滚是全有还是全无，取决于部署框架
  • 可能需要对次要修复部署进行完整的回归测试（取决于 QA 控制）
于 2012-10-30T10:22:13.473 回答