共计 2531 个字符，预计需要花费 7 分钟才能阅读完成。
策动 & 编辑|雅纯
上一讲咱们讲了继续部署的 4 个指标：精确可预期的部署后果、部署过程不影响线上服务、有可继续部署的软件增量、低成本和高效地部署公布，并剖析了如何做到。
可是，有了好的继续部署实际，如何能力规模化落地呢？
承载实际最好的形式就是工具。继续部署过程的最好载体就是流水线，因为继续部署自身就是一个逐级递进的流水线。
继续公布流水线
如上图所示，咱们能够看到，从最早拉取代码、构建、验证、部署，整个过程是一个逐级递进的过程。如果代码发生变化，或配置发生变化，或代码依赖发生变化，流水线将会被从新触发。从拉取代码开始，直至流程执行实现或中断。咱们会依照构建的配置来构建制品，将制品保留到制品仓库，产生构建产物，接下来咱们会基于构建产物做验证，验证通过就能够进入部署，部署胜利就意味着这个个性曾经被胜利发到了线上的运行环境中。
在图中咱们减少了几个局部，包含研发治理平台、配置核心、监控核心、运维公布平台。
在最简化的流水线外面咱们看不到这些，然而在大家的理论工作当中会存在这几个概念：
- 咱们在执行流水线的时候，会跟研发治理平台做交互，比方是否有对立的构建规定；在整个公司的层面或者是部门的层面是否有对立的束缚，比方代码的检测规范，可能是公司对立的，这些都会在研发治理平台保护。
- 配置核心是治理服务的个性开关和动静配置等，配置核心的配置是须要下发给运行中的服务的。
- 流水线的公布过程和监控核心买通，监控数据的变动，反过来会影响公布，所以整个流水线和监控须要做集成。这个集成能够通过人，然而更好的形式是通过工具链。
- 部署策略个别积淀在运维同学的脑子里，或者是运维平台的工具里，这些策略要被利用到流水线上，部署过程当中流水线和运维公布平台有十分强的耦合。
- 另一个很重要的点，咱们在运维平台上有很多安全策略和敏感信息，这些是不能够，或者是不能承载在流水线或者代码中的，须要通过运维公布平台做管控。
这样，咱们通过流水线跟咱们现有的研发零碎就造成了有机的整合，以达到高效公布的目标。
一个好的流水线是怎么的
既然流水线是如此重要的载体，一个好的流水线应该是什么样的呢？
首先，流水线应该是可形容的 ，流水线能够像一幅画或者一项工作那样被具象化进去。特地重要的是流水线能够具象化表白研发模式，通过流水线保障公布流程的一致性。基于流水线能够把实际疾速复制，如利用同一条流水线的模板就能够利用同一个实际。
第二，流水线应该是可观测的 。整个公布过程发到哪、发了什么、两头有什么问题、胜利还是失败，是可观测的，并且这个观测是和监控买通的，这样就能够保障公布过程有保障。
第三，整个过程是自动化的 。比方构建完不须要到验证阶段再手动触发，整个过程是主动流转的。流程应该建设在工具的根底上，不依赖人，这就是自动化。
以从右到左、面向终态的思维来看，咱们的终态是有一个稳固可预期的零碎，为此须要找到一个稳固可预期的软件的制品版本，达到一致性的环境，再去进行部署。
部署的时候要合乎上一讲所说的 4 个准则。无论是继续集成、继续测试，无非是要获取确定的软件制品，而后依照 4 个准则部署下来，所有的这些能力和流动都是为了最终的指标来服务的。
流水线利用举例
咱们联合例子来看一下确定继续交付流水线的整个过程。
首先是模板。咱们会在团队或者是公司层面有一些最佳实际的模板，比如说有
JAVA 后端利用的流水线模板，流程上从代码扫描开始，执行测试，而后是构建和部署。有了这个模板之后，能够在团队内所有 JAVA 后端利用间复用。
第二是团队对立管控和能力复用，比方对立定义某些环境变量，在运行中注入 Secret 或者账号信息，这些不心愿在代码中明文存储，然而咱们会通过工具注入上来。假如把 devops.test.local 作为咱们本人的研发治理平台，咱们能够通过相似上图的形式与之集成，咱们也能够在平台里定义敏感信息，或者保护公共变量，而后在每一个流水线的步骤外面援用，达到全局复用的成果。
其次，流水线是具备观测性的。咱们能够晓得当下流水线的状况，最新的一次运行是否实现、有没有间断失败的状况等。从流水线视角能够看到一个 feature 从开发、集成到公布的整个阶段是什么样的，两头是否存在问题。比方图中的流水线从开发完到集成之间有很长时间的期待，这里可能存在阻塞，能够下钻进行进一步剖析。
上面是咱们基于云效做的 DevOps 计划大图。云效蕴含残缺的 DevOps 研发工具链。以需要的角度，在工作看板外面拿到相应的开发工作就能够开始开发，提交代码，而后在代码层面做检测和平安扫描，接着执行构建，集成，验证，最初上线。
右上角的“1-1-1”是咱们的愿景 ：咱们心愿做到 1 个小时的公布前置时长，从代码提交到公布到生产 1 个小时实现，咱们心愿每天至多有 1 个可公布的版本，咱们心愿每一个利用每周至多公布 1 次。
“1-1-1”可能帮忙咱们去发现在整个集成公布过程当中存在的问题 ：为什么不能做到 1 小时的公布前置时长？由哪些起因导致的？这时就须要找到问题的关键所在，其实是给本人设定一个指标，而后再看现状。现状跟指标之间有一段距离，这个间隔就是须要解决的问题。
有了基于云效的 Codeup、Flow，也能够构建其余的交付模式，比如说挪动 APP 的继续交付模式。
另一个是 Web 利用，常见的云的服务端的公布。
或者是前端，间接把相应的前端构建物发送到 CDN，这些都是比拟常见的公布流程。
总结
- 公布是将软件个性增量交付给最终用户的过程；
- 软件交付须要做到精确、低成本及高效；
- 继续部署应该: 精确、可预期的部署后果; 部署过程不影响线上服务; 有继续可部署的软件增量; 及低成本、高效地部署公布；
- 精确地部署须要明确的待发布制品，明确的运行环境及明确的公布过程和公布策略；
- 无服务中断的部署过程须要做到滚动式部署、部署可观测、可干涉及可回滚；
- 软件增量应该是残缺的，可验证的及可独立部署公布的单元；
- 低成本、高效的部署公布须要缩小公布批量及保障公布的顺畅性
- 继续公布流水线是规模化标准团队软件公布的无效伎俩，软件的公布过程应该做到可见、可控、可减速、可度量。
下一讲，咱们将进入研发模式篇：构建团队协同交付的流程。
点击下方链接收费体验云效继续交付流水线 Flow！
https://www.aliyun.com/produc…