【华为敏捷/DevOps实践】9.以终为始，再谈持续交付流水线( 二 ) _部署

所有交付的功能特性都是基于假设：Wethat[ this ][for these ]will [this ].We will know we arewhen we see[thisfrom the ].
这就是假设驱动开发的概念。所以单向的不叫持续交付（价值），要实现闭环还需要反馈回路来验证假设。
完整的闭环才是价值交付的过程，只有验证了假设，才能说将价值交付给了客户。
通过发布，获取反馈，验证假设，进一步完善价值，进而提出新的需求（假设）。
SAFe的理论，大多来自于。SAFe的模型，是三步工作法的另一种解读。

文章插图
什么叫持续交付？多快的频度算是持续？一周一个版本还是一天多个版本？
视不同类型的产品，在类生产环境验证之后，有两条路径，一条是传统的软件模式，部署到生产环境，或是商业软件产品的客户交付过程，就意味着发布给最终客户，那么这里需要有一个业务的决策过程，是否可以将特性交付给最终客户。
另一条是通过技术解偶的手段，实现即使是部署到了生产环境，也并不意味着发布给了最终客户，例如特性开关和Dark。相较于第一种，这里业务决策过程就相对灵活一些。
以上两条路径，均需要技术手段来支撑，实现将特性先行发布给一部分用户，以及功能对用户是否可见。
“黑启动已经让每个人的信心达到几乎对它冷漠的程度…...大家根本就不担心…...我不知道，在过去5年里的每一天中，发生过多少次代码部署…...我根本就不在乎，因为生产环境中的变更产生问题的概率极低……”，John 在担任运营副总裁时说了上述的话，随后他发表了一天十次部署的著名演讲，随后他来到Etsy，Etsy的自助式部署流水线，使得“任何想要执行部署的人都能直接部署……董事会成员也可以执行部署……甚至连小狗都可以！……在一个普通的工作日里，刚到上午8点整，就有大约15个人和小狗开始排队……“
下图是2010年时Etsy的持续部署流水线工具，已经将集成进去，”提交代码之前，在自己开发环境执行了4500多个单元测试……UT运行仅需要不到1分钟，外部调用打桩……提交到主干后，CI服务器上立即执行7000多个自动化测试用例…...通过并行测试，11分钟执行完毕，分钟……到2011年，每天25-50次部署”

文章插图
从上述的例子，可以看出技术对业务极大的赋能。如果我们能做到每天几十次的部署到生产环境，那么每次的变更又能有多大，一个月一次的版本，发布的时候的确需要严格审核，一天几十次呢？不难想象，此时的业务决策该有多简单，甚至可能不需要决策过程，这就是技术能力赋能给业务决策的体现，也是精益中强调小批量的原因。
按需发布，让特性发布成为业务和市场决策，而不是技术决策。
通过金丝雀发布，可以小批量的选择环境进行试验，待金丝雀验证通过再发全量。而滚动发布，使得这一流量切换过程更加平缓，一旦出现问题，可以自动回滚。

文章插图
通过特性开关，可以保证应用上线后，功能开关先不打开，然后由业务人员根据场景进行决策，通过开关中心打开新功能，经过流量验证新功能。特性开关将部署与特性发布解耦，结合基于环境和用户群的蓝绿或是滚动发布，可以实现对不同的用户群进行不同功能的投放，实现A/B测试，进一步增强了假设驱动开发的能力，可以基于不同的假设路径，进行快速灵活的发布验证。