主干研发模式 vs 特性研发模式-优快云博客

背景：

研发团队当前用特性分支开发模式，因此多个研发需求交叉并行，但问题是测试环境只有一套，面临争抢环境的问题。

在这个背景下，负责研发事务的领导提出了主干研发模式，即谷歌和腾讯采用的Trunk based development.

优势在于，测试可以随时部署master分支，随时验证master分支，环境部署的始终是master分支，不存在抢环境验证的问题。

特性分支开发模式：

特性分支开发模式是指为一个或多个特定的需求 / 缺陷 / 任务，从主干分支上拉出特性代码分支（branch），在其特性代码分支上完成相应的开发（一般会经过增量测试）后，再把它合并（merge）到主干分支准备发布的开发模式。

主干开发模式

主干开发模式是指所有的开发人员仅在一个主干分支（master）上进行协作开发，一般不允许新建其他长期存在的开发分支，所有的代码提交均需要在主干分支上完成。通常这种开发模式下，开发者需要有较高频率的代码推送行为，一般一天至少提交一次，当主干分支达到发布条件后，就从主干分支上拉出发布分支（release）进行版本发布。开发或测试过程中发现的代码缺陷也会直接在主干上进行修复，再根据实际需求 cherry pick 到特定的发布分支或是进行新版本发布。

特性分支开发模式 vs 主干开发模式

特性分支开发模式

优势：

分工协作规则明确。整个开发周期中的各个步骤基本都有对应的分支，对于开发人员只需要遵循规则，在对应分支上进行对应的开发工作即可。
特性开发周期相对宽松。因为特性分支是有对应的开发者负责，所以对于一些较大较复杂的特性可以在特性分支上开发完成后再合入主干。
特性测试相对友好。特性功能的测试在特性开发分支关闭前都可以进行，这给测试预留了较多时间，对测试的能力要求也相对宽松，很多时候都可以进行手工测试。

劣势：

分支管理复杂。因为特性分支开发的基础就是多个分支协作，所以必然会创建很多不同的特性开发分支和特性基线分支，如果有些分支在生命周期结束后开发人员没有及时进行销毁，时间一长，必然会造成无效分支冗余，管理成本将会越来越高。
学习成本高。因为特性分支开发模式中不同的分支有不同的功能，代码在分支上的流转也需要遵循一定的规则，且不同的团队的规则也会不同，这样对于开发人员的学习成本很高，且因为分支较多，在代码的流转过程中也会增加出错的几率。
合并冲突多，迭代速度慢。因为特性的开发都是要在整个特性开发完成结束后才合并到主干分支上，这就意味着特性分支与主干分支一定会存在较多差异，并且特性分支的生命周期越长，与主干的代码差异越大，合并冲突也越多，解决冲突相应的时间和人力成本也会越高。同理迭代速度也会越慢。
需要较多的测试环境。每个特性分支的测试都至少需要准备一个测试环境，且在该特性通过测试前会一直占用，所以并行的特性开发数量会受到限制。

适用范围：

特性功能开发/测试周期比较长，测试主要依靠人工测试的产品。
版本迭代速度不需要太快的产品。

主干分支

优势：

分支简洁，实践简单，分支管理成本低。
开发人员易上手，过程出错率低。
合并冲突少，解决冲突成本低。
版本迭代速度快，更符合持续集成和持续交付的理念。

劣势：

对团队的基础架构和协作能力的要求很高。若合入主干的代码质量出现问题将会阻塞整个团队的进度，所以一方面需要团队成员的个人能力和协作能力比较强；另一方面需要完善的持续集成能力的基础平台，提供回滚等快速解决问题的能力。
对团队代码质量要求高，评审机制要求完善。需要有完善的 CR 机制，将问题代码尽可能在发布的前置环节发现并解决。
自动化测试能力要求非常高。需要完善的冒烟和单元测试，确保每次合入主干的代码的正确性。因为主干模式合入代码的频率很高，所以人工测试肯定是无法保证及时响应测试需求，一定需要自动化测试。
需要有特性隔离方案。主干开发模式中因为特性功能需要拆分成很小的粒度，有时候特性功能需要相互依赖，但相互依赖的特性又无法保证同一时间上线，就十分有可能出现半成品特性功能，这时候就需要采用特性隔离方案将这些半成品特性进行隔离。

适用范围：