交付和发布的区别，你真的懂吗？
今天在星球内部群里，有同学提了一个问题：公司经常搞线上运营活动，每次活动都要封版一个月。活动结束后往往用大量时间去解决堆积的需求，结果发布后线上质量不太好，这种问题该如何解决？
这种问题很常见，但这种现象很奇特，很多人把持续集成、持续交付和持续发布三者的概念搞混了。以为不断的迭代需求不断的开发测试，测试通过就要发布上线。但其实，交付和发布是两件完全不同的事情。
这篇文章，我会从需求迭代入手，聊聊交付和发布的关系，以及在规模化敏捷中经常提到的一个术语：版本火车。
需求交付和发布
按照我们常规的理解来说，一个软件产品的迭代交付模型如下图所示：
业务方或者产品提出需求，并组织需求PRD评审，评审通过后进入设计环节。UI设计/架构设计评审通过，进入编码实现并提测，测试通过后软件产品理论上就达到了符合产品预期设计的标准，即产品本身的功能和质量满足交付要求。接下来就是线上发布，让用户使用，这个环节已经进入了产品运营阶段。
在很多同学的认知里，测试通过就要发布到线上，如果线上封版不允许发布，那这个软件迭代交付流程就卡住了，就如我开篇提到的案例所示：活动封版，活动结束后用大量时间去解决堆积的需求，发布后线上质量不太好。出现这种问题其实是一种恶性循环：
- 封版导致整个迭代流程停滞，堆积了大量的需求；
- 一次性发布多个迭代需求，每迭代引入的风险未进行充分评估和测试；
- 只顾着吞吐需求，但新上线的功能缺少线上监控预警，故障响应和应急手段缺乏；
从持续集成持续交付的角度来说，封版只是线上发布停止，而不意味着需求迭代和研发测试交付停止。每个迭代周期内，技术同学最后应该交付的，应该都是满足需求和质量可靠的软件产品。
要解决文章开头这位同学遇到的问题，其实方案早就有了，那就是 Release Train Model，俗称版本火车。
什么是版本火车
版本火车可以将它理解成一种软件发布计划，在互联网公司应用较为普遍。形象一点形容就是：固定时间发一趟车（一次迭代），如果符合要求能赶上发车时间就让上车（测试通过，按时交付），如果存在问题就下车等下一班车（有严重bug或交付延期），以免影响其他乘客的正常出行（其他需求的上线和产品迭代）。
因为是固定的时间周期发布，为了确保每次都能顺利发车，就需要制定严格的计划，确保从需求设计到研发测试交付都能按时完成对应的工作。在一个发布周期内，很多工作要提前开展，比如需求评审、方案评审、编码实现等。
完成这些事项后如果打算上车（该版本发布），就需要按照计划时间完成对应的工作，比如在规定时间内完成代码自测并合并到本次发布的版本中，如果无法准时提测就等下一趟车。
从代码分支管理角度来说，版本火车模型大致如下图所示：
- 统一使用release1.0这样的命名方式，做好权限管理；
- 开发新功能时，从master拉取一个feature-name分支，在该分支完成功能开发和自测；
- 如果该功能要上车，则按照时间要求完成自测并提交merge request，code review通过后合并到release1.0；
- 代码合并后通过单元测试和自动化测试后，正式将release分支代码提测；
- 正式完成线上发布后，再将release分支代码合并至master，本次版本火车完成；
最后，回到本文的主题：发布和交付的区别。
发布大家都了解，将测试验收通过的软件产品对外发布，让用户使用，并通过持续的业务和产品运营创造业务价值。而交付则是按照约定时间完成一个符合要求的软件产品（纯技术角度就是一个release分支的代码集）。
即使由于业务运营活动要求，线上发布暂停，但交付本身是可以持续迭代的。每次发车，从上一个release拉取分支进行开发测试，测试验收通过再合并到release，等待线上可以发车时候，跟随上车发布。
当然要达到版本火车顺利运转，至少需要满足几个条件：
- 严格的计划管理；
- 强大的项目管理能力；
- 良好的代码分支管理；
- 全面的测试覆盖和验证能力；
- 完备的CICD流水线支撑能力；
最后也是最重要的一点，线上发布需要及时将配套的技术和业务监控补全，还要有较好的应急响应机制和故障处理手段。
