选择具有DevOps思维模式的分支策略

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

是否打算在Azure DevOps中使用 Team Foundation 版本控制 (TFVC) DevOps？你可能有几个问题，例如：

TFVC 是一种集中式版本控制系统，用于维护代码并使团队更高效。它提供协作和一致的代码共享、发布和评审功能。

保持简单！

通过采用有效的分支策略，你将：

若要接受DevOps，请务必保持分支策略简单，并努力实现高质量。一些建议：

从简单的策略开始，根据需要进行发展
对分支使用一致的命名约定
- 个人执行的工作的功能/用户名/说明 - 示例 ，features/sandra/sdk-java
- 特定于工程 bug 的工作的 bugfix/username/bugid - 例如 bugfix/takashi/707
- 计划版本的 releases/version - example ， releases/V1.00
经常反向集成 (RI) 并合并到主分支
鼓励一致的代码评审 - 垃圾传入和垃圾
使用：
- 门控签入
- 自动测试

创建用于标识 可交付 发布单元的源代码管理结构。 可释放单元的概念是这一策略的基础部分，史蒂夫·圣让描述如下：

版本控制与传递的物理单元。
支持分支和发布模型的主要单元。
可以位于 Suite、Application-或 Component-level。
对于套件，所有应用程序都必须同时进行版本和修补。例如，Microsoft Word和Excel是Microsoft Office套件的一部分。 Visio不是，因为它可能独立于Microsoft Office套件的其余部分发布或修补。
在 TFVC 中，这将是团队项目节点下的根节点。
可以等同于 Git 中的存储库

通常，必须仅支持一个生产版本，同时对新功能进行并行缺陷更正和开发。典型示例包括网站、企业业务线应用程序和临时工具。

从简单的仅主分支策略开始。

initial branch diagram

使用每个签入到主分支、运行自动测试（如果成功）将版本部署到开发 (开发) 环境中自动触发生成。

分支	生成	环境	备注
Main	CI_Bld	Dev	每次签入到 main 时触发

完成发布周期后，创建发布分支。使用发布分支稳定发布，并在主版本中继续开发下一个版本。反向集成 (RI) ，并经常将验证的 bug 修复与主分支合并，以最大程度地减少整体技术债务。

Version 1.0 is released

自动执行生成和发布，使其：

分支	生成	管道	备注
Main	CI_Bld	Dev	每次签入到 main 时触发
V1.00	RC_Bld	开发 - QA ->> UAT - 过渡 ->> Prod	每次签入以释放时触发

当版本 2 成为候选版本时，可以更新现有的 RC 生成管道以指向 V2.00 分支。它现在将像 V1.00 在当前版本时一样生成和发布。

当需要支持多个生产版本（例如 Word 等商业解决方案）时，可以扩展分支策略。

对于需要支持的每个已完成发布周期，请使用功能隔离创建新的发布分支并继续进行下一版本开发。请注意反向集成 (RI) 从 v1.0 和 v2.0 合并到 main。它们表示发布到生产的 bug 修复。

Version 2.0 is released

通过使用 简单的 分支策略并采用 一致的命名约定，你将能够支持：

清单

从领域吸取教训 - 要避免的事项