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

印象里全文没有一键部署的概念，至少写的时候没有要去强调一键部署，甚至自动化都不是我想说的。核心是技术行为与业务决策的分离，以最大化的优化可控的技术部分，来支撑变化的业务部分，一键是方式，不是目的，更不是唯一。事实上，在部署流水线里面，甚至可以消除掉一键那个动作。
流水线的存在，接管了底层的基础设施，包括计算，存储，网络，无论是On，还是On Cloud；接管了PaaS层，开发人员无需太关注是虚拟机，还是容器，也不必太多了解K8s的配置和编排，以及DTAP不同的环境的配置和差异；甚至接管了上面使用的自动化工具，包括版本库、制品库、持续集成、自动化构建、自动化测试工具、自动化部署工具。
这些都将成为流水线的一部分，所以流水线越来越不可或缺，不同的语言也好，架构也好，环境也好，容器也好，微服务也好，K8s也好，都可以往流水线上挂。流水线也就成为Dev to Ops事实上的标配和代名词。
所以流水线的作用，第一，接管和屏蔽底层环境的差异；第二，自动化流程引擎；第三，挂载执行分层分级的流水线任务。
流水线也是“持续稳定可重复的提供高质量的价值”的重要不可或缺的实践，服务于持续交付同时也是的终极目标。
流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。
所有在流水线上面挂载的任务，理论上都应该服务于这一目的，所有不对这一目的提供价值的任务，理论上都不应该存在于流水线之上，都应该被消灭。
通过流水线，让部署成为日常的、低风险的工作，来解决开发与运维之间“根本的、长期的冲突”：开发负责对市场变化做出响应，以最快的速度将新功能或者变更上线。而IT运维则需要为客户提供稳定、可靠和安全的IT服务。同时公司对不同部门的考核和激励不同，更是让开发部门与运维部门的目标和动因之间存在巨大的冲突。
通过小批量的、独立的快速交付周期，让各个功能/服务团队之间彼此解耦，快速获取反馈，快速验证问题，并不能解决问题，它只是让你快速失败，If you fail，fail fast 。（所以在里，失败原本就是学习的一种方式）
通过频繁、快速的生产环境部署，保证稳定可重复的自动化部署。
通过，Black，让功能早在发布之前，就已经部署到生产环境中，并已经进行了多次小范围验证。
为下游工作而优化，从而在业务需要时，可以不依赖于技术，可以自行进行功能的发布。
因此技术提供给业务的是一个自服务平台，正如将运维能力封装成自服务提供给开发一样。
业务域
我们再来看业务域。
“持续交付跟这三个（持续集成、持续部署、持续发布）都不同，它是一种组织的能力，这种能力让组织可以持续的角度价值，具体是否采用以上三种技术实践并不一定，而且还必须考虑其他非技术因素，比如团队管理模型，需求结构，项目管理方式，人员能力等等。所以这个持续交付和以上3个不是一个层次的问题，但他们之间确实有互相推动影响的关系。”——徐磊
持续集成与持续部署是技术域的事情，持续交付是业务域的，而持续发布，个人认为两者都有，但偏业务层面多一些。按需发布，所以发布还是业务的决策。
业务需要决定发布策略：
发布节奏不需要与开发节奏保持一致，开发保证环境和功能是随时可用的，业务来决定发布策略。

文章插图
持续交付流水线是Flow，是价值交付的过程，但如何确定交付的就是客户想要的价值？