选择有效的分支策略

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

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

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

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

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

本文探讨一些常见的分支策略,帮助你做出正确的决策。

与存储库范围的 Git 分支不同,TFVC 分支的范围是路径范围,而不是轻量级。 设置条形图用于创建高分支,并且仅在需要代码或发布隔离时创建分支。

仅主

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

Main Only branching strategy

风险:TFVC 标签的可变性和缺乏历史记录可能会增加更改控制的风险。

从主要唯一分支策略开始, 从战略上开始 ,采取其他策略,根据需要演变为更复杂的策略。

开发隔离

需要维护和保护稳定的分支时,可以从分支对一个或多个开发分支进行分支分支。 它可实现隔离和并发开发。 工作可以通过功能、组织或临时协作在开发分支中隔离。

Developer Isolation branching strategy

分支中可能存在更改。 始终将 (FI) main 集成到 开发 分支并解决合并冲突。 然后反向集成 (RI) 更改回 。 跨分支保持相同的质量条。 (BVT 生成和运行生成验证测试,) 开发方式与在主节点上执行的操作相同。

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

功能隔离

功能隔离是开发隔离的特殊派生,允许你从分支一个或多个功能分支,如图所示,或者从开发分支分支进行分支。

Feature Isolation branching strategy

需要处理特定功能时,创建功能分支可能是个好主意。

使功能工作生存期和关联的功能分支生存期保持短生存期。 经常从父分支转发 (FI) 更改。 仅当满足一些已同意的团队条件(例如完成定义)时,才能反向集成 (RI) 回到父级。 节点上的功能回滚可能成本高昂,并且可能会重置测试。

发布隔离

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

Release Isolation branching strategy

当发布准备好锁定时,是时候为发布创建新的分支了。

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

注意:没有分支方案是不可变的,这就是为什么你注意到在发布分支上执行的紧急修补程序的原因。 改进每个策略以满足你的要求,而不会忘记复杂性和相关成本。

服务与发布隔离

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

Service Release Isolation branching strategy

如果需要服务模型供客户升级到下一个主要版本和每个版本的其他 Service Pack,请使用此策略。

与发布隔离一样,当发布准备好锁定时,会创建 维护 隔离和 发布 分支。 从 服务向 服务从维护服务 转发到 发布。 锁定 发布 分支以防止修改。 将来的服务更改可以在 服务 分支上完成。

如果需要这种隔离级别,请为后续版本创建新的服务分支和发布分支。

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

尽管不建议,但可以通过引入其他 修补程序 分支和相关发布方案来继续改进策略。

Service HotFix Release Isolation branching strategy

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

问答

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

通过将分支保持生存期较短,合并冲突会尽可能少。

为什么仅在必要时分支?

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

为什么删除分支?

目标应该是尽快将更改恢复 为主 ,以缓解长期合并后果。 暂时、未使用且丰富的分支会导致团队的混乱和开销。

是否可以跨项目对代码库进行分支?

是。 不建议这样做,除非团队必须共享源,并且不能共享通用过程。

代码升级策略怎么样?

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

开发 合并到 分支时,为何未检测到任何更改?

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

TFVC 和 Git 分支策略之间是否存在相似之处?

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

作者:杰西·侯文、马库斯·费尔南德斯、迈克·福里和来自阿尔姆|的威利·肖布DevOps游侠。 可以 在此处与他们联系。

(c) 2015 Microsoft Corporation。 保留所有权利。 本文档提供“原样”。本文档中表达的信息和视图(包括 URL 和其他 Internet 网站引用)可能会更改,而无需通知。 您自行承担其使用风险。

本文档未向您提供任何 Microsoft 产品中任何知识产权的任何合法权利。 可以复制本文档并将其用于进行内部参考。