选择有效的分支策略

  • 项目

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

为 Team Foundation 版本控制 (TFVC) 存储库创建分支有助于隔离风险。 如果一个团队有五名或十名以上的成员一起开发软件项目，试想一下他们一般要面临哪些挑战：

  • 该工作组有几个（或者更多）不同的功能团队，每个团队负责开发一组适度分散的功能。 但每个团队又依赖于其他团队构建的功能。 您需要隔离由其中每个团队所做的工作而引入的更改风险，但最终需要将这些团队的所有工作合并到一个产品中。

  • 测试团队在测试时需要稳定的代码版本，同时开发人员需要继续开发新功能，而新功能偶尔会破坏产品的稳定性。

  • 软件有两个以前的版本和一个正在开发的版本。 即使大部分开发工作都投入到当前版本中，也必须继续为旧版本提供支持，这需要不时地发布 Service Pack、关键修补程序和安全修补程序以及其他变更。

本文探讨了一些常见的分支策略，可帮助制定正确的决策。

与存储库范围内的 Git 分支不同，TFVC 分支的范围是路径，并且不是轻量级的。 为创建分支设置高标准，并且仅在需要代码或发布隔离时才创建分支。

仅限主分支

“仅限主分支”策略可以基于文件夹，或将主文件夹转换为分支，以启用其他可见性功能。 将更改提交到主分支，并可选择使用标签指示开发和发布里程碑。

“仅限主分支”分支策略

风险：TFVC 标签的可变性和缺少历史记录会增加变更控制的风险。

从“仅限主分支”分支策略有策略地进行分支开始，并根据需要采用其他策略来演变为更复杂的策略。

开发隔离

如果需要维护和保护稳定的主分支，可以从主分支创建一个或多个开发分支。 它支持隔离和并行开发。 可以按功能、组织或临时协作在开发分支中隔离工作。

开发人员隔离分支策略

主分支中可能发生更改。 始终将主分支正向集成 (FI) 到开发分支并解决合并冲突。 然后将更改反向集成 (RI) 回主分支。 跨分支保持相同的质量标准。 在开发分支上生成和运行版本验证测试 (BVT)，方法与在主分支上相同。

注意：使用此策略，团队可能会永远保留开发分支，这可能生成大型合并票证历史记录。

功能隔离

功能隔离是开发隔离的特殊派生，允许从主分支（如图所示）或从开发分支创建一个或多个功能分支。

功能隔离分支策略

需要处理特定功能时，创建功能分支可能是一个好办法。

使功能工作和关联功能分支的生存期保持短暂。 频繁正向集成 (FI) 在父分支中进行的更改。 仅当满足某些商定的团队标准（例如完成的定义）时，才反向集成 (RI) 回父分支。 在主分支上进行功能回滚可能代价高昂，并且可能会重置测试。

发布隔离

发布隔离从主分支引入一个或多个发布分支。 该策略允许在发布时进行并发发布管理、多个并行发布以及代码库快照。

发布隔离分支策略

当准备好锁定发布时，就可以为发布创建新分支了。

切勿从主分支正向集成 (FI)。 使用访问权限锁定发布分支，以防止意外修改发布分支。 对发布分支进行的修补和热修复可以反向集成 (RI) 回主分支。

注意：分支方案都不是不可变的，这就是会在发布分支上执行热修补程序的原因。 在不忽视复杂性和相关成本的情况下，发展每项策略以满足要求。

服务和发布隔离

服务和发布隔离策略引入了服务分支。 此策略允许在发布时对服务包和代码库快照进行并发服务管理。

服务发布隔离分支策略

如果需要一个服务模型供客户升级到下一个主要发布以及每个发布的其他服务包，请使用此策略。

与发布隔离一样，服务隔离和发布分支是在准备好锁定发布时创建的。 切勿从主分支正向集成到服务分支，或从服务分支正向集成到发布分支。 锁定发布分支以防止修改。 将来的服务更改可以在服务分支上完成。

如果需要该隔离级别，请为后续发布创建新的服务和发布分支。

服务、修补程序、发布隔离

可以通过引入其他修补程序分支和关联的发布方案来继续改进策略，但不建议这样做。

服务修补程序发布隔离分支策略

此时，你已成功探索了一些常见的 TFVC 分支方案。 可以对其进行改进，或调查其他策略（例如 功能切换、切换功能开关），以确定某个功能在运行时是否可用。

问答

为什么分支应该生存期较短？

通过使分支保持生存期较短，可尽可能减少合并冲突。

为什么仅在必要时创建分支？

要采用 DevOps，需要依赖于生成、测试和部署的自动化。 更改是连续、频繁的合并操作，并且由于合并冲突通常需要手动干预，因此更具挑战性。 因此，建议避免创建分支并依赖其他策略（例如功能切换）。

为什么要移除分支？

目标应该是尽快将更改集成到主分支，以缓解长期合并后果。 临时、未使用的大量分支会导致团队混乱和产生开销。

是否可以跨项目创建代码库分支？

是的。 不建议这样做，除非团队必须共享源并且无法共享通用流程。

代码提升策略呢？

代码提升策略感觉像是瀑布开发时代的遗物。 它通常具有较长的测试周期，以及单独的开发和测试团队。 不再建议使用此策略。 有关此策略的详细信息，请参阅分支指南。

将开发分支合并到主分支时，为什么未检测到任何更改？

你可能忽略了以前的合并中的更改，例如，使用 keep source 冲突解决选项。 有关详细信息，请参阅将开发分支合并到主分支：没有要合并的更改。

TFVC 和 Git 分支策略之间有相似之处吗？

TFVC 功能隔离分支策略类似于 Git 主题分支。

作者：ALM | DevOps Rangers 的 Jesse Houwing、Marcus Fernandez、Mike Fourie 和 Willy Schaub。 可以在此处与他们联系。

(c) 2015 Microsoft Corporation。 保留所有权利。 本文档“按原样”提供。本文档中表达的信息和观点（包括 URL 和其他 Internet 网站引用）如有更改，恕不另行通知。 您自行承担其使用风险。

本文档未向您提供任何 Microsoft 产品中任何知识产权的任何合法权利。 您可为了内部参考目的复制和使用本文档。