主干开发：让Scrum真正运转的工程实践
Scrum团队承诺在每个迭代结束时交付可运行的软件。这一承诺只有在支撑团队按需集成和发布能力的工程实践真正到位的情况下才具有可信度。在许多Scrum团队中，这些实践并不存在。团队在长期存在的功能分支中工作——这些分支与主代码库分离数天甚至数周——然后在迭代结束时面临痛苦的集成事件，所有人的工作同时合并。集成成本高昂，反馈被延迟，持续交付的承诺停留在理论层面而非付诸实践。主干开发是弥合这一差距的工程实践。
长期功能分支的问题
功能分支存活的时间越长，它与主干的偏差就越大。其他开发者每一次向主干提交都会产生偏差，这些偏差在合并时都需要协调。一个活跃了两周的分支可能需要在合并前协调数百个从未见过的变更。这产生了几种形式的浪费：合并冲突消耗开发者时间处理非增值的协调工作；集成意外——单独运行良好的功能在与其他进行中的工作集成后失效——导致返工和延误；延迟反馈意味着功能中的设计或架构问题在工作完成很久后才对团队可见，此时修改成本最高。
主干开发在实践中意味着什么
每天至少向主干提交一次。 主干开发的核心纪律是每位开发者至少每二十四小时将自己的工作与主干分支集成一次。这意味着任何工作在协调之前与主干偏离的最长时间为一天。合并冲突变得小而频繁，而非大而偶发。集成意外在数小时内被发现，而非数周后。
使用不超过两天的短期分支。 实践主干开发的某些团队完全不使用分支，直接提交到主干。其他团队使用非常短暂的分支——通常限制在一到两天的存续时间——作为完成后立即合并的工作单元。两天的限制是一种启发规则，而非硬性规定：目标是防止使集成变得昂贵的偏差积累。无法在两天内完成并合并的分支，通常意味着工作需要进一步分解。
使用功能标志而非分支隐藏未完成工作。 对主干开发最常见的异议是：「我们不能将未完成的工作合并到主干——这会破坏生产环境。」功能标志解决了这个问题。功能标志是一个配置开关，控制某项功能是否在生产环境中激活。未完成的功能合并到主干时处于生产环境中关闭的标志之后。代码在主代码库中被集成和测试，但在团队准备好打开标志之前不会对终端用户开放。这将部署与发布分离：代码可以在生产环境中存在而不对用户可见。
技术前提条件
主干开发需要一个使频繁集成安全的工程环境。快速自动化测试是最重要的前提条件：如果构建需要四十五分钟，开发者就不会频繁集成，因为反馈周期太慢。主干开发团队需要一套能在数分钟内（而非数小时）提供有意义覆盖的测试套件。功能标志基础设施是第二个前提条件。在代码中临时管理的功能标志很快会成为技术债务；适当的功能标志管理系统允许标志被整洁地创建、管理和退役。最后，小提交文化——将工作分解为小型、独立可部署增量的习惯——是一个比技术性更强的文化前提条件，但同样重要。
如果您的Scrum团队在集成或弥合仪式与交付之间的差距方面遇到困难，XNM的项目与计划交付实践可以帮助您评估工程实践，并建立使敏捷交付具有可信度的技术基础。