软件开发生产线 CODEARTS-持续交付流水线:业务域
下载软件开发生产线 CODEARTS用户手册完整版
业务域
我们再来看看业务域。
“持续交付跟这三个（持续集成、持续部署、持续发布）都不同，它是一种组织的能力，这种能力让组织可以持续的交付价值，具体是否采用以上三种技术实践并不一定，而且还必须考虑其他非技术因素，比如团队管理模型，需求结构，项目管理方式，人员能力等等。所以这个持续交付和以上3个不是一个层次的问题，但他们之间确实有互相推动影响的关系。”——徐磊
- 发布策略与发布节奏
持续集成与持续部署是技术域的事情，持续交付是业务域的。而持续发布，本文认为两者都有，但偏业务层面多一些。按需发布，因此发布还是业务的决策。
业务需要决定发布策略：
- 什么时候发布？
- 发布哪些特性？
- 发给哪些用户？
发布节奏不需要与开发节奏保持一致，开发保证环境和功能是随时可用的，业务来决定发布策略。
- 假设驱动开发
持续交付流水线是Flow，是价值交付的过程，但如何确定交付的就是客户想要的价值？
所有交付的功能特性都是基于假设：We believe that [building this feature] [for these people] will achieve [this outcome]. We will know we are successful when we see [this signal from the market].
这就是假设驱动开发的概念。所以单向的不叫持续交付（价值），要实现闭环还需要反馈回路来验证假设。完整的闭环才是价值交付的过程，只有验证了假设，才能说将价值交付给了客户。通过发布，获取反馈，验证假设，进一步完善价值，进而提出新的需求（假设）。
SAFe的DevOps理论，大多来自于DevOps Handbook。SAFe的模型，是DevOps Handbook三步工作法的另一种解读。
- 多快的频度算是持续
什么叫持续交付？多快的频度算是持续？一周一个版本还是一天多个版本？
视不同类型的产品，在类生产环境验证之后，有两条路径：一条是传统的软件模式，部署到生产环境，或是商业软件产品的客户交付过程，就意味着发布给最终客户，那么这里需要有一个业务的决策过程，是否可以将特性交付给最终客户。另一条是通过技术解偶的手段，实现即使是部署到了生产环境，也并不意味着发布给了最终客户，例如特性开关和Dark Launch。相较于第一种，这里业务决策过程就相对灵活一些。
以上两条路径，均需要技术手段来支撑，实现将特性先行发布给一部分用户，以及功能对用户是否可见。
- 持续部署对业务的赋能
“黑启动已经让每个人的信心达到几乎对它冷漠的程度…...大家根本就不担心…...我不知道，在过去5年里的每一天中，发生过多少次代码部署…...我根本就不在乎，因为生产环境中的变更产生问题的概率极低……”，John Allspaw在Flickr担任运营副总裁时说了上述的话，随后他发表了一天十次部署的著名演讲，随后他来到Etsy，Etsy的自助式部署流水线，使得“任何想要执行部署的人都能直接部署……董事会成员也可以执行部署……甚至连小狗都可以！……在一个普通的工作日里，刚到上午8点整，就有大约15个人和小狗开始排队……”
2010年时，Etsy的持续部署流水线工具已经将ChatOps集成进去，“提交代码之前，在自己开发环境执行了4500多个单元测试……UT运行仅需要不到1分钟，外部调用打桩……提交到主干后，CI服务器上立即执行7000多个自动化测试用例…...通过并行测试，11分钟执行完毕，MTTR20分钟……到2011年，每天25-50次部署”。
从上述的例子，可以看出技术对业务极大的赋能。如果我们能做到每天几十次的部署到生产环境，那么每次的变更又能有多大，一个月一次的版本，发布的时候的确需要严格审核，一天几十次呢？不难想象，此时的业务决策该有多简单，甚至可能不需要决策过程，这就是技术能力赋能给业务决策的体现，也是精益中强调小批量的原因。
- 低风险发布
按需发布，让特性发布成为业务和市场决策，而不是技术决策。
通过金丝雀发布，可以小批量的选择环境进行试验，待金丝雀验证通过再发全量。而滚动发布，使得这一流量切换过程更加平缓，一旦出现问题，可以自动回滚。
通过特性开关，可以保证应用上线后，功能开关先不打开，然后由业务人员根据场景进行决策，通过开关中心打开新功能，经过流量验证新功能。特性开关将部署与特性发布解耦，结合基于环境和用户群的蓝绿或是滚动发布，可以实现对不同的用户群进行不同功能的投放，实现A/B测试，进一步增强了假设驱动开发的能力，可以基于不同的假设路径，进行快速灵活的发布验证。
