摘要：在这里聊一聊主干开发你需要知道的7件事。
现在各大公司流行主干开发，什么是主干开发，什么是分支开发、具体定义、流程是啥，这里不做知识普及，想要了解的童鞋到网上去搜一搜，再来读本文。作者本人经历过分支开发，也走过分支开发到主干开发演变的全过程，经历过演变中的阵痛。团队适应主干开发后，也踩过不少坑，当然主干开发带来的好处也是比比皆是。咱这里聊一聊主干开发你需要知道的7件事。
1、主干开发的错误认识一：主干开发会改进产品质量
不要迷信主干开发，也别妄想通过主干开发来改进产品质量。首先要明确的是产品质量好不好与主干开发、分支开发没啥本质关系。说到底，feature做慢一点，做少一点，多进行code review，DT，相对来说质量会好很多。如果主干开发同等时间做的功能过多，测试不充分，产品发布以后，同样问题多多。即使是分支开发，留下充足的时间去控制质量，质量相对来说也会很好。之前的经验是迁移到主干开发后，GIRA报表上明显可以看出，每个月迭代出去的feature越多，engineer release前defects的统计越糟糕。同样最终产线上产生的CFD（customer found defects）就会越多。
总结来说：产品质量的是好还是坏与主干开发、分支开发没半毛钱关系。产品质量还是依据开发本身最根本的原则，多花时间测试来发现问题，产品上产线问题会越少。
2、 主干开发的错误认识二：分支开发的问题，主干开发都能解决。
分支开发通常会遇到这个问题：当分支的代码合并到主干时，通常在一定周期内，出包都是个问题，即使出了包，经常会有大规模的block issues。如果觉得主干开发可以彻底解决这问题，实际上也是现实的。当采取主干开发模式时，基本上可以解决其中的一部分问题，但是有些问题，不是通过流程来解决的。
首先主干开发基本上不存在出包问题，理论上只要代码能够入仓，就能够跑过CI上的所有检测，能够顺利出包。但是我们都知道主干开发一个最重要的要是就是代码要通过feature toggle来控制，通常情况下，开发中的feature都是toggle off的。也就是每天的包，不同的团队，打开不同的feature toggle来测试。但是当同时打开几个feature toggle时，或者产品决定要同时release几个feature时，这时候没有人可以保证这些新feature可以在一起可以同时正常工作。特别时有些功能时横向的变化，有些功能时纵向的变化，中间的交际不同的团队如果没有沟通好，没有提前进行继承，同样会产生大规模的block issues。举个例子：之前在开发的功能，我们的SVP坐飞机从硅谷飞到芝加哥给客户做demo。上飞机前打开我们的feature toggle，但是软件在他的机器上一运行就crash。但是在我们自己的开发机器上是好的。他发了一个log给我们以后就上飞机了，说下了飞机在看怎么回事。我们分析了他的feature toggle列表，与我们的做了一个比较，发现其中有3个feature toggle不一样，当打开其中一个feature toggle后，我们可以重现这个问题。 为了demo顺利进行，在后台给他关闭了那个冲突的feature toggle，SVP下了飞机以后到酒店再试就好了。他不太明白咋回事，我们废了好半天才跟他解释我们产品关于feature toggle的设计与实现，以及问题产生的原因。
总结来说：主干开发在代码合并的角度上比分支开发要好一些，但是还是需要不同团队多交流，来解决。甚至看起来完全没有关系的feature放在一起，没有经过继承测试，同样会导致严重的问题。
3、 主干开发的错误认识三：主干开发增加开发效率，让迭代更快。
由于没有了分支合并主干的工作，大家会觉得主干开发效率更高，可以让产品迭代更快，实际上这是个误区。首先主干开发对于功能的开发效率比分支开发低，原因后面会提到。所以总体时间差距不大。我之前分支开发模式下时每月一个迭代，切到主干开发也是每月一个迭代，做到功能规模差距不大，所以这个说法并没有根据，由于切换过程中的一些不习惯，短期内效率会变低。
总结来说：主干开发的目的不是为了增加开发效率，也没有什么特定的因素可以根本加快开发效率。
4、 主干开发的副作用：相对于分支开发，主干开发的代码会更“烂”。
主干开发，通常来说没有达到release标准的代码会运行在真实的产线中，只是代码通过if/else来通过feature toggle来让产线的代码不会走到开发过程中的feature逻辑。首先任何人都无法保证所写的代码逻辑完全正确，所以主干开发对于code review以及开发者测试的要求极高，换句话说就是对于开发人员的要求极高，这也是很多团队无法开展主干开发模式的根本原因。一旦你的代码再toggle off的时候也会导致bug，那么产线就要回滚版本，或者立刻出EP（emergency package）来fix这个问题(作者本人就犯过这种错误，if else的位置多包含了一个判断，导致现有功能一个逻辑处理异常)，其成本极高，所以主干开发的commit到主干的每一行代码，都要及其重视。同时由于定义了大量的feature toggle以及遍布到处的if/else，代码看起来相对比较糟糕，还有就是为了配合一些特定的发布流程，几乎常常要变更feature toggle的定义，这些都是主干开发带来的负面影响。通常我们会有feature toggle + feature option来控制一个feature的使能，意思就是当feature toggle ON的时候，代码才会执行，但是feature本身是由可配置到feature option来打开或者关闭该功能，当产品功能真正上线成熟后，开发团队应该删除feature toggle的逻辑，但是很多开发团队没有意识或者无暇顾及这些，导致“烂”代码一直存在，这也是主干开发的一些弊端或者要着重要注意的地方。
总结来说：主干开发过程中，其工作量要比分支开发更多，其出错概率也更高，对于开发人员要求也更高，代码写的也更烂。
5、 主干开发的优势一：主干开发天然支持灰度发布以及A/B Test。
上面说了主干开发那么多问题，但是为什么大家还要做主干开发，当然其有很多好处。最大的特点就是主干开发流程中，feature toggle的存在，让开发本身天然的支持了灰度发布以及A/B Test。如果说5年前，灰度发布，A/B Test这种理念比较先进，大家决定比较高深。当产品采用主干开发模式以后，那么你就会发现原来这个东西真的很简单。由于feature toggle的存在，可以通过服务器的配置可以针对企业级别，用户级别的feature toggle控制。以我之前产品的开发模式为例，开发过程中，开发团队开发feature toggle进行开发，当功能达到一定成熟度，可以申请进行“Blue Channel”，所谓的Blue Channel就是所有产品的开发人员以及通过特殊渠道申请加入的一群人，规模在500-1000人左右。
这个所有的Blue Channel就是对于feature toggle管理的一个集合，在这个Channel中所规定的feature toggle按照一定的设定来进行开发与测试。这个Channel的包极其不稳定，主要是产品功能并未做完全，各种feature在也会出现 “干架”的情况。由于我们所做的产品是我们日常都要用（例如Welink这种），所以加入这个Channel的非开发人员是需要勇气的。再往后，feature成熟度更高，就会扩展到公司层面的一些人，规模在几千人左右。通常老板们会加入这个Channel，经常拿这个版本给客户做Demo，我们把这个Channel叫做“Purple Channel”。当功能更完善时，会提交申请进入“Green Channel”，对外叫做“EFT Channel”，通常会有几万用户在用，也会给一些想要试用新功能的部分客户试用。当产品的功能达到一定发布标准时，产品进入最后一个Channel，叫做“Golden Channel”，然后通过预定的灰度发布计划逐步把Feature Toggle给所有用户打开最终达到GA。客户再根据自己的需要决定Turn On/Turn Off feature option。整个过程中，没切换一次channel，都要提交相关的流程申请，还有更换feature toggle。当产品达到GA标准以后，理论上需要删除feature toggle相关的代码。
总结来说：主干开发天然支持灰度发布以及A/B Test，这也是很多公司切到主干开发的主要原因。
6、主干开发的优势二：主干开发比分支开发更容易的控制feature的发布。
分支开发，当决定在某个release时，会把代码合并到主干，但是如果后续开发测试过程中，如果在规定发布时间内达不到质量要求，这时候就比较尴尬了。到底是延迟发布时间，还是把代码给删掉？这是分支开发的一个弊端。主干开发基本上不存在这个问题，主干开发通常会提前一定时间开出release branch（不同公司、不同产品有不同的规定，我之前的产品基本上在3周-6周）。当产品测试发现质量达不到要求是，只要产线toggle off就可以了。我之前公司有“一进一出”的评审，“一进”就是确定release branch开出时，该feature是否打开feature toggle进入系统级别的测试。“一出”就是根据测试结果来决定那些feature可以打开feature toggle进入本次release，基本上不需要额外的工作就可以完成。还有就是产品灰度发布的过程中，甚至GA初期，功能出现任何较大的问题，都可以通过feature toggle立即关闭该功能。对于产品质量的管理更方便。
总结来说：主干开发对于一个feature什么时候release，release过程中的一些问题，相对分支开发更容易处理。
7、 主干开发的优势三：更简单的版本管理。
分支开发经常会面临一个这样的问题：一些客户的特殊需求，我们开出一个分支来开发，甚至直接在这个分支上发布给客户。如果合到主干，就要面临想主干开发那样如何隔离的问题，但是本身不是主干开发，所以这是一个严重的负担，如果停留在分支上，后续该用户的持续升级面临版本管理的问题。而主干开发来说，这个需求就是一个feature toggle控制的一个功能，开发测试完成正常进入release，只不过该feature toggle一直存在并且只针对特定的可以打开而已。
总结来说：主干开发的设计就是简化版本管理，在主干上按照一定的规则拉出一个分支发布，比分支开发管理更简单。
总结
分析了主干开发相对于分支开发的各种利弊，大家可以根据自己团队的实际情况来看待我是用主干开发还是分支开发。如果主干开发的优势对自身产品可有可无，那么没有这种必要来切换。但是如果有必要，但是团队的成熟度和技能达不到，也不适合切换到主干开发。甚至当你决定要切换到主干开发，一定要有心里准备来应对变革过程中遇到的各种问题。当然当你的团队经历了这些阵痛并真正适应了主干开发，那么团队就的成长也是巨大的。