软件开发生产线 CODEARTS-持续交付流水线:技术域
下载软件开发生产线 CODEARTS用户手册完整版
技术域
“客户并不一定需要每一个green build，PM/发布经理按业务需求可选择任意一个，在任何时候自动化交付给客户；在部署、交付、发布的上下文里，dev和ops的最高境界是无为，赋能PO那帮人做业务决策，别烦我。”——Martin Liu。
从这句话中我们可以看出，从业务上，并非每一个功能都需要发布给每一位用户，而是根据不同的业务上下文，来决定哪些功能发布出来，针对哪些用户进行开放。发布决策，由业务来做。而技术需要的，是提供高效的交付能力，并保持随时可发布的版本状态。
技术层面的核心，在于保障价值的交付能够顺畅、频繁且快速的通过整个价值交付流水线 。
- SAFe的持续交付流水线
下面让我们看看SAFe对持续交付流水线的划分，事实上，“Develop on Cadence, Release on Demand”也是来自于SAFe的内容。中间的持续集成与持续交付，正是关系部署前置时间的部分。前端的持续探索，属于产品、设计与开发内容，而这三部分，组成了技术域的发布火车。后面何时发布、如何发布，则是按业务的需求决定。
- 聚焦于部署前置时间
"How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?" ——Mary Poppendieck
修改一行代码，上线需要多少时间？这一指标决定了你能多持续、多稳定的交付，决定了MTTR，多久服务可以恢复、多快能够上线一个严重的缺陷修复、多快能够发布一个服务并获取价值反馈。这一指标，就是部署的前置时间。
部署前置时间，开始于工程师在版本控制系统中提交一个变更，截止到变更成功的在生产环境中运行、为客户提供价值，并生成有效的反馈和监控信息为止。
部署前置时间将整个价值流交付过程分成了两段，前一段的活动，主要是产品、设计和开发，具有高度的不确定性和变化性，需要创造性的工作，且很多工作无法复制。后一段的活动，主要在集成、测试和部署运维，相比起来，相对技术更可控。
所以部署前置时间的核心，是把可控的部分做到极限，力求可预见性和自动化，将可变性降到最低，来支撑变化的部分。
- 目标是分钟级的部署前置时间
通过小批量代码交付，在不同环境中通过不同层级的自动化测试与探索性测试，快速进行验证，同时持续将成功验证的变更部署到下一环境，从而在DTAP（开发、测试、验收、生产）不同环境中形成自动化的测试和部署节奏，这也就是部署流水线的概念。为实现部署流水线，需要版本管理、自动化测试、持续集成、自动化部署、环境管理，以及松耦合架构等的协调统一。
- 分层分级的部署流水线
“高质量的交付”，质量如何界定？功能和非功能的都算上，质量验证的手段也是分层的，验证就是反馈，为了快速获取反馈，这些手段分布在整个流水线的各个阶段。
部署流水线，是保障质量并缩短部署前置时间的有效支撑。同时，部署流水线，是分层分级的。
- 从影响范围来看，分为个人级、项目级、版本级、解决方案级的流水线。
- 执行的频度单位，分别是分钟级、小时级、以天为单位、和以周为单位。
- 分别对应不同的环境（DTAP）：Development、Testing、Acceptance、Production。
各个层级，在不同的环境上，执行不同的测试，这也与理想的测试金字塔分层测试相互对应。
每个层级的目的、和预设的反馈回路、涉及的范围、验证的方法与内容、定位问题区间都有所不同。
- 流水线越来越成为开发运维一体化的代名词
开发与运维之间“不可调和的矛盾”，可以通过流水线来解耦。流水线成为开发和运维人员最常使用的平台，从日常的提交代码自测，到提交到主干的持续集成，到测试和准生产环境的自动化与手工的验证，以及各级环境之间的部署和环境拉平。
很多人对于自动化都喜欢强调或追求“一键”的概念，然而一键只是方式，不是目的，更不是唯一。事实上，在部署流水线里面，甚至可以消除掉一键那个动作。
流水线的存在，接管了底层的基础设施，包括计算、存储、网络，无论是On Premise，还是On Cloud；接管了PaaS层，开发人员无需太关注是虚拟机，还是容器，也不必太多了解K8s的配置和编排，以及DTAP不同的环境的配置和差异；甚至接管了上面使用的自动化工具，包括版本库、制品库、持续集成、自动化构建、自动化测试工具、自动化部署工具。
这些都将成为流水线的一部分，所以流水线越来越不可或缺。不同的语言也好、架构也好、环境也好、容器也好、微服务也好、K8s也好，都可以往流水线上挂，流水线也就成为Dev to Ops事实上的标配和代名词。
所以流水线的作用，第一，接管和屏蔽底层环境的差异；第二，自动化流程引擎；第三，挂载执行分层分级的流水线任务。
流水线也是“持续稳定可重复的提供高质量的价值”的重要不可或缺的实践，服务于持续交付，同时也是DevOps的最终目标。
流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。
所有在流水线上面挂载的任务，理论上都应该服务于这一目的，所有不对这一目的提供价值的任务，理论上都不应该存在于流水线之上，都应该被消灭。
说到这里就不得不说一说能支持自动化部署流水线的工具——CodeArts。
在流水线方面，CodeArts提供可完全自定义的自动化部署流水线，关联版本库、编译构建、部署等多环节的功能，提交代码自动触发流水线，帮助团队轻松实现持续交付。任务配置中支持挂载子流水线，流水线分层分级管控。
- 解决开发与运维之间“根本的、长期的冲突”
通过流水线，让部署成为日常的、低风险的工作，来解决开发与运维之间“根本的、长期的冲突”：开发负责对市场变化做出响应，以最快的速度将新功能或者变更上线，而IT运维则需要为客户提供稳定、可靠和安全的IT服务；同时公司对不同部门的考核和激励不同，更是让开发部门与运维部门的目标和动因之间存在巨大的冲突。
通过小批量的、独立的快速交付周期，让各个功能/服务团队之间彼此解耦，快速获取反馈，快速验证问题，DevOps并不能解决问题，它只是让你快速失败，If you fail，fail fast。（所以在DevOps里，失败原本就是学习的一种方式）
通过频繁、快速的生产环境部署，保证稳定可重复的自动化部署。
通过Feature Toggle（功能开关/特性开关）、Dark Launch（灰度上线），让功能早在发布之前，就已经部署到生产环境中，并已经进行了多次小范围验证。为下游工作而优化，从而在业务需要时，可以不依赖于技术，可以自行进行功能的发布。
因此技术提供给业务的是一个自服务平台，正如将运维能力封装成自服务提供给开发一样。
