Release Flow: 为持续交付而优化的分支策略

在快节奏的软件开发世界中，有效的分支策略对于确保顺利协作、并行开发和及时发布至关重要。Release Flow是一种基于主干的分支策略，使团队能够实现更快的迭代、持续集成和可扩展性，目标是最大程度地减少向客户发布新功能所需的时间，同时仍保持高度的稳定性和可靠性。

开发

Release Flow下，在开发功能或者修复缺陷时，第一步是从主干分支（main/master）中创建出一个新的本地分支，使用这个新的本地分支来编写代码，这些新分支需要是“短暂”的，即这些分支需要尽早地（通常是一天到几天内）合并回主干分支，在合并前可以按需插入代码审阅、构建及单元测试、代码安全扫描等环节

主干分支需要被保证是永远“可用”的，即主干分支上的代码需要保证可成功构建以及通过所有的自动化持续集成流水线环节。

推荐的本地分支名：feat/xxx, user/xxx/feat/xxx等

如果某些功能的开发时间较长怎么办：仍然尽早合并，但是使用功能开关，避免未开发完整的功能破坏主干的完整性和可用性

条件允许的情况下，可以将主干分支的代码持续部署到一个临时的环境中，以便于开发者和QA可以尽快地对其进行检验，获得更紧密的反馈周期。

发布

在当前发布周期的开发任务完成后，即可从主干分支中创建出发布分支，以进行当前发布周期的发布工作。发布分支是专门为发布创建的长生命周期的分支。它们提供了隔离和稳定性，允许开发团队准备和测试版本，而不会干扰主线分支上正在进行的开发。

在大多数情况下，发布分支的代码不会直接交付到生产环境，可以按需构建版本发布的流水线来进行逐步发布，如先发布到预发布环境做最后的验收测试，验收测试通过后，则通过金丝雀部署等方式部分发布到生产环境，通过线上监控和用户反馈收集确认版本可靠性后，再最终发布到所有线上用户。

推荐的分支名：rel/202401, rel/m121等，没有必要也不推荐使用语义版本(1.2.1风格)作为分支名

部分发布的方式：

  1. 线上部署新版本的同时，保留老版本，结合流量控制（通过Service Mesh等技术），将随机的少部分请求(例如5%)引导至新版本上。
  2. 直接部署新版本，结合功能开关，将新版本的功能首先提供给部分用户（比如内部测试用户）

注意：发布分支不会合并回主干分支，一旦某发布分支的版本在生产环境已经完全被更新，这个发布分支就失去了存在的意义，可以直接删除掉

缺陷修复

当有缺陷被确认时：

  1. 首先从主干分支中创建出修复分支，在修复分支上进行编码
  2. 将修复分支合并到主干分支
  3. 将修复分支上的改动挑选(cherry-pick)到发布分支

为什么从主干分支而非发布分支进行修复：如果我们首先修复发布分支，则很有可能忘记将此修复合并回主干分支，从而导致被修复的缺陷在下个版本发布时再次出现

一个例外情况是：如果此缺陷只在发布分支存在，在主干分支中已经因为重构或者其它原因不再存在，则可以无视主分支，直接将修复分支合并到发布分支

一些经验

参考资料: 1.Release Flow: How We Do Branching on the VSTS Team 2.Trunk Based Development 3.Asseco SEE DEM Developer guide