好的持续部署实践，如何规模化落地|学习笔记-阿里云开发者社区

开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：好的持续部署实践，如何规模化落地】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/82/detail/1280

好的持续部署实践，如何规模化落地

内容介绍：
一、持续发布流水线

二、基于云效的 Devops 模式

三、总结

四、课后作业

一、持续发布流水线

之前给大家提一个问题，持续部署的一些实践，那么怎么把持续部署的实践规模化的落地？

就是一些发布上的好的实践、运维上的好的实践以及测试中的好的实践，怎么能让它们很好的落地，在整个持续交付，持续部署过程中能够沉淀下来呢？

在有了持续部署相应的一些实践、好的规则、好的方法之后，需要有相应的载体才能够让它承载下来。

这里提到了持续发布流水线的概念，也就是一个载体。

实践最好的承载方式就是承载在一个工具中，不需要我们去记忆，也不需要去掌握去学习，但是我们每天都在跟它打交道，这就是最好的承载方式。部署过程的最好载体就是流水线，因为本身流水线就是一个逐级的递进的概念。

上图可以看到，从最开始拉取代码，到构建、验证、部署。他是一个逐级向下的过程。

比如说，拉取代码的时候会有触发一个要求，就是什么情况下该去做拉取代码。比如，如果代码发生变化，配置发生变化或者代码的依赖发生变化，那就意味着需要重新走一次流水线，所以就会进行拉取代码。然后整个系统会进行构建。构建就是根据构建的规则去构建出一个制品来，然后把这个制品放到制品仓库，放到制品仓库之后，有了构建产物，就会去进入这个构建产物去做验证。验证完了之后，如果通过就会进入到部署环节。整个部署成功之后，就成功的把这个特性发到了线上的运行环境中。

就是上图中间的几个项目，分别是研发管理平台，配置中心，监控中心用发布平台。在最简化的流水线里面是看不到这些东西的，但是在实际工作中，往往会存在这样几个概念。首先，研发管理平台就是在拉取代码做构建的时候，我们会跟平台做一些交互，例如说有没有统一的构建规则，在整个公司的层面或者说部门的层面，有没有一些统一的一些约束，比如说我们的 P3C 的代码规约的一个检测标准，它可能是公司统一的，那这个时候就需要从同一个地方去拿下来。同时有哪些依赖的代码项可能也要在这个管理平台上去维护。

配置中心就是说我们整个的服务，不管是刚前面的特性开关，还是动态配置，还是其他一些配置，一般都会有通过配置中心去管理，这个配置中心的配置是需要下发到运行中间的，整个流水线的发布中间，在发布前要跟监控中心去打通，因为发布需要知道监控的一些数据的变化，而这些数据的变化反过来会影响我们的发布。所以整个流水线要在这个地方跟监控做一个集成，这个集成可以通过人去看，但最好的方式还是通过公链去做。

在部署中间会有部署策略，这个部署策略一般是沉淀在运维同学的脑子里的或者运维的工具里。那这些工具和策略能力要被应用到整个流水线上，所以在整个部署过程中，我们会跟运维发布平台做一个非常强的一个耦合。另外一个重要的一点就是运维上会有很多安全性的东西或者安全策略，这些东西不能承载在流水线或者代码中，那么这些东西也会通过用运维发布平台去做一个管控，所以在这样的一个情况下通过这些手段，让流水线跟现有的其他的一些研发系统做了一个有机的整合，做到一个非常高效的一个发布。

那么流水线应该是什么样子的呢？

首先它应该是一个可描述的，就是说流水线本身可以像描述一段代码或说一句话一样去描述它，它是一个研发模式的一个具象化的表达，比如说看到流水线就知道发布模式是什么样子。第二个，这个流水线可以保证整个发布流程是一致的，不会出现偏差。我们前面说的这个一致性的问题。第三个，基于这个流水线，可以把实践快速的去复制，我只要应用同一条流水线的模板，我就可以应用同一个实践。

第二，流水线应该是可观测的，就是整个发布流水线本身，发到哪、发布了什么、中间有什么问题，成功还是失败都是是可观测的，并且这个观测是可以跟监控的数据可以一起去观测的。这样就可以导致整个发布过程是有保障的。同时是可以看到的。

第三，整个过程应该是自动化的，就是包括两个方面，一个就是发布过程是自动化的，就是说，当构建完成之后并不需要人去让它进入验证阶段再触发起来。而是整个过程是自动运转的。整个流程是建立在一个工具的一个基础上，而不是通过人把它落地下去的。

这个就是自动化，它是可执行，可运行的，其实这里简单的，转变一下思维方式，我们不从左到右，而是从右到左来去看。用一种终态思维，然后就是说最右边是需要有一个稳定可预期的一个系统。这个时候就要去找到一个稳定的软件制品的版本，然后再找到相应的一致性的一个环境，然后再去做响应的一些部署，部署的时候符合刚才说的四个原则。然后无论是持续集成也好，持续测试也好，无非就是要一个明确确定的那个软件制品。然后把这个东西按类似的原则部署上去。那么所有的能力跟活动，都是为了最终个目标去服务的，这样就能很简单的去理解这个持续发布流水线，持续发布流水线可以帮助我们很好把流程在工具上能够快速的落地，能够快速的复制出去。

下面看一些具体的例子。

’这是一个流水线的一个模板化的描述。

这个流水线是云效做的例子。首先就是说在一个团队或者一个公司层面，会有一些最佳实践的模板。比如说 java 的发布模板，因为该实践应该有代码扫描、测试、构建跟部署。这是我们认为的一个比较好的模板，当然我们可以制定更多的模板要求。有了这个模板之后，就可以在整个团队内所有应用间复用了。

第二个，就是团队的统一管控或者是统一能力的一个复用，比如可能会有一些统一的环境变量。就是在运行，在发布中间，我会注入一些 SET 或者我的账号的一些东西，这些是我不希望在代码中明文去存储的。但是会从发布平台上注入下去。

那就可以通过第二种方式跟我们的发布平台打通，我们假设把这个 Devops.test. Local 作为我们自己的研发管理平台，那我们可以通过这个方式把它给它作为一个很好的一个集成，那我们可以在平台里去定义一些敏感的东西或者说公共的一些东西。然后在流水线的步骤里面去应用它，就达到了一个全局层面的复用的一个能力。

流水线本身应该是可以具备观测性的，首先我们要能知道当下整个流水线的情况是什么样子，最新的、是不是有完成的、还是在进行、有没有连续失败的情况，这种情况说明需要我们去关注。

从上图中的第二个流水线我们可以看到，在一个 feature 从开发到集成到发布的整个阶段是什么样子的，它中间存在一些问题，比如说这个流水线从开发完到集成这个之间有很长的时间等待，那我们想知道这中间发生了什么，就可以去研究它。另外我们发现它最后的发布失败了，但这个失败之后，可能到现在没有人去处理，那就需要知道哪里发生了什么。

二、基于云效的 Devops 模式

基于一些现有的工具，这是对于云效看板和云效代码头托管，codeup 和 flow，包括阿里云里头构建了一个完整的一个Devops的一个研发模式。

它是什么呢？

就是说从需求的角度来说，拿到相应的需求，然后在任务看板里头拿到相应的开发任务，就可以做相应的一些代码的一些 push 。完了之后在代码的层面可以做响应一些鉴定和安全扫描，完成之后可以做相应的一些构建，然后是集成、验证，最后上线这样的一个过程。这个大家就是比较常见的一个持续发布的流程。

图中的右上角1-1-1的三条是我们提出来的一个愿景，就是说我们希望一个小时的发布前置时长，也就是说从代码提交到发布到生产环境，希望一个小时能够完成。另外一个，就是我们希望每天至少能够做一次的发布一个版本。然后针对团队来说，每个应用每周至少能够发布一次。

愿景就是能够帮助我们去发现我们整个在集成发布过程当中的一些问题。为什么不能一个小时做到，是哪些原因导致？那这个时候就可以找到影响你发布的一个问题的一个关键所在。所以其实它是给你设定了一个目标，然后再去找相应的一些现状。现状跟目标之间是有一段距离的，这个距离就是 gap ，这里相应的 gap 就是要去解决的问题。

有了这个之后，像云效的 codeup ,flow。你也可以去构建其他的一些交互模式，比如说移动 app 的一个持续交互模式。可能会不太一样，而且 flow 它也可以跟 jenkins 去打通，对你现有的一些资产也能够复用。

然后另外一个，比如说像 web 应用，也就说我们常见的云的一个服务端的发布。

另外一个就是说像前端的，通过 flow 直接把相应的前端代码上到 CDN，这是一些比较常见的发布的流程，在这里跟大家做一个简单的一个分享。

三、总结

首先，发布是将软件特性增量，然后交付给最终用户的一个过程。

软件交付需要做到准确低成本和高效。

持续部署应该做到：准确可预期的部署结果；部署过程不影响线上服务；有持续可部署的软件增量，并且能够低成本，高效的部署发布。

如果要做到准确的部署，就要有明确的待发布的制品，明确的运行的环境及明确的发布过程和发布策略。

无服务中断的部署过程要做到滚动式的部署，就是说我是滚动的两个版本，可能会同时存在。

部署的的过程，必须做到观测，如果有问题，能够快速可干预。如果来不及了，可以进行回滚，就是要做到滚动、可观测、可干预和可回滚。

软件增量应该是完整的，可验证的和独立部署发布的单元。

低成本，高效部署发布，需要减少发布的一个批量并且保障发布的一个顺畅性。

最后就是持续发布流水线是规模化，规范团队软件发布的一个有效手段。我们发现很多团队还是直接各自在自己的电脑上发布，每个人的流程都不一样，那么发布的制品的质量的一致性也很难去保证。我们不仅要保证制品的一致性，版本的一致性，环境的一致性，质量的一致性，发布流程的一致性。所以整个软件的发布过程应该做到可见可控，这样才可以做到可加速，并且可度量。