多分支集成发布各种坑怎么填？| 云效

小明的研发团队要发布一个版本，这个版本包含了多个功能特性，每个不同的特性之间有较强的独立性。不同的特性由不同的开发人员或开发小组分工完成。

他们在不同的特性分支上开发，彼此相互独立、互不影响。

一个特性开发完成后就提交测试，这个过程不影响其他特性的正常开发，全部已完成的特性全部合并进行测试和发布。在提交测试，集成合并时碰到了这样的问题：

• 对于某个公共模块的修改出现了合并冲突

• 由于一个特性分支的集成，导致整个版本集成失败

版本发布时间在即，为不影响整体进展，需要快速分离影响了整个集成的那个特性分支。

如果你是小明，这时你会怎么做？

小明的研发团队又要发布一个版本，整个版本有 A、B、C、D 四个功能特性一起合并集成，分别在分支 A、B、C、D 上开发。临近发布前，市场侧通知由于某种原因功能特性 B 不能发布，也就是这次发布需要剔除分支 B。按照严格的集成发布策略，A、C、D 这 3 个特性分支需要重新构建，分别再经过集成测试、预发验证，然后到生产发布。但是，这样做是有成本的。

如果你是小明，在效率和质量之间你会怎么选？

这两个情景遇到的问题，在多分支并行开发集成发布中很常见，如何快速、灵活、高效又实用地解决这类问题，成为众多小明的刚需。

阿里巴巴集团内部经历并仍在经历着大量多分支集成发布的实践，这些实践被提炼成了一套阿里的分支策略，形成了阿里分支模式，并通过公共云产品云效 Flow 对外部研发用户输出。

当使用云效Flow 分支模式时，小明的两个场景问题将可以得到灵活高效地解决。

场景一：如何快速分离影响整个集成的那个特性分支

小明可以直接在再次运行分支时，删除已集成分支，执行流水线时将会自动进行以下操作：

• 基于分支管理器中设置的基础分支（如 master），创建新的 release 分支

• 除了该特性分支外的其他在云效配置中的其他分支合并到 release 分支

• 基于 release 分支的最新内容运行流水线

场景二：发布在即需求被砍，如何平衡效率和质量？

小明发现云效分支可以按环境/流程，自由地集成，考虑到本次上线的时间对后续项目进度非常关键，小明选择了跳过中间的测试阶段、预发阶段直接部署到正式环境，为了最大程度避免质量风险，小明还使用了云效Flow的发布前人工审核卡点能力，最终变更没有耽误正常发版，也未出现任何风险。

云效 Flow 这套灵活高效的分支模式可以让用户只关心集成和发布哪些特性分支，而对发布分支创建和管理、分支间合并等一系列工作，托付给云效完成。

下面详细介绍云效分支模式原理及实践。