2. 版本发布模式的取舍
在《持续交付 2.0》一书中提到，版本发布模式有三要素：交付时间、特性数量以及交付质量。
这三者是相互制衡的。在开发人力与资源相对固定的情况下，我们只能对其中的两个要素进行保证。
传统的项目制发布模式是牺牲了交付时间，等待所有特性全部开发完成并经历完整人工测试后才发布一次新版本。但这样会使得交付周期变长，并且由于特性数量较多，在开发过程中的不可控风险变高，可能会导致版本无法按时交付。不符合一个成熟的大型项目对于持续交付的要求。
对于持续集成的思想来说，当我们的集成频率足够高，自动化测试足够成熟且稳定时，完全可以不用一股脑地将特性全堆在一次发布中。每开发完成一个特性就自动进行测试，完成后合入等待发布。接下来只需要在特定的时间周期节点自动将已经稳定的等待中的特性发布出去即可。这对于发布频率越来越高，发布周期越来越短的现代大型项目中无疑是一个最优解。
3. 分支策略
与大部分团队一样，我们原有的开发模式也是分支开发，主干发布的思想，分支策略采用业界最成熟也是最完善的 Git-Flow 模式。
可以看出，该模式在特性开发，bug 修复，版本发布，甚至是 hotfix 方面都已经考虑到位了，是一个能应用在生产环境中的工作流。但整体的结构也因此变得极为复杂，不便管理。例如进行一次 hotfix 的操作流程是：从最新发布前使用的主干分支拉出 hotfix 分支，修复后合入到 develop 分支中，等待下一次版本发布时拉出到 release 分支中，发布完成后才能合回主干。
此外，对于 Git-Flow 的每一个特性分支来说，并没有一个严格的合入时间，因此对于较大需求来说可能合入时间间隔会很长，这样在合入主干时可能会有大量的冲突需要解决，导致项目工期无端延长。对此，做大型改造与重构的同学应该深有体会。
针对这一点，我们决定大胆采用主干开发，主干发布的分支策略。
我们要求，开发团队的成员尽量每天都将自己分支的代码提交到主干。在到达发布条件时，从主干直接拉出发布分支用于发布。若发现缺陷，直接在主干上修复，并根据需要 cherry pick 到对应版本的发布分支。
这样一来，对于开发人员来说需要的分支就只有主干和自己 working 的分支两条，只需要 push 与 merge 两条 git 命令就能完成所有分支操作。同时，由于合入频率的提高，平均每人需要解决的冲突量大大减少，这无疑解决了很多开发人员的痛点。
需要说明的是，分支策略与版本发布模式没有银弹。我们采用的策略可能并不适合所有团队的项目。提高合入频率尽快能让产品快速迭代，但无疑会让新开发的特性很难得到充分的手工测试及验证。
