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

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

课程地址：https://developer.aliyun.com/learning/course/772/detail/13510

内容介绍：

一、持续发布流水线

二、具体示例介绍

三、总结

一、持续发布流水线

讲到此处，提一个问题，就是在想有很多同学或者有很多人有很好的想法，有很好的持续部署一些实践，怎么样把程序部署的实践规模化的一个落地。

比如前面也提到了，有很多发布上的一个好的实践，测试中的好的实践，如何把这些东西，能够很好的落地下去，在整个持续交付持续部署过程中能够沉淀下来。其实遇到过这样的问题，或者思考过这样的问题，这里其实很容易就跳到另外一个概念里，其实有了持续部署相应的一些实践，在这些实践里需要有相应一些载体，能够让它承载下来，把这些实践好的规则，好的方法，能够有相应一些载体给承接下来，这就提到了另外一个知识持续发布流水线。

这样的一个概念作为一个载体，实践的承载，最好的方式就是承载在一个工具中，不需要去记忆学习，持续部署流水线持续部署的过程的最好载体就是一个流水线，因为本身就是一个逐级的一个递进的一个流水线的概念，可以看到从最早的开始拉取代码做构建，做验证，做部署，是一个逐级往下走的一个过程，比如拉取代码时，会发生什么事情呢？

会有触发的一个要求，什么情况下该去做拉取代码呢？比如代码发生变化了，配置发生变化，代码的依赖发生变化，那就意味着是重新走一次流水线了，所以会去拉取代码。

拉取代码之后，整个系统会去做一把构建，怎么做构建，会根据构建的一个规则，去构建出一个制品，所以把制品放到了去仓库，然后放到成品仓库之后有了构建产物，就会去进入件产物去做验证，验证完了之后，如果通过了就可以进入到整个部署环节了。

整个部署成功之后，成功的把特性发到了一个线上的运行环境中，大家看到中间，其实加了几个地方，一个研发管理平台配置中心监控中心英文发布平台，如果最简化的热线里面其实看不到这些东西，但是实际上在大家实际的工作中往往是会存在这样几个概念：研发管理平台是什么，是在拉取代码做构建的时候，其实是会跟一个平台做一些交互，比如有没有统一的构建规则整个公司的层面或者部门的层面，有一名没有一些统一的一些约束比如p3c，代码规约的一个检测标准是什么，公司统一时候需要同一个地方去拿下来，同时有哪些依赖的代码可能在管理跟上去维护整个的服务，不管是刚前面说到特性开关，还是动态配置，还是其他的一些配置，会有通过配置中心去管理，配置中心配置是需要下发到运行中间，整个流水线的发布，中间在发布前肯定要跟监控中心去打通，因为发布肯定需要知道监控的一些数据的变化，而这些数据反过来会影响发布，所以整个流水线跟监控，在这是要做一个集成，当然集成可以通过人去看，但最好的方式还是通过工具链去把他做掉，然后再部署中间我们会有部署策略，而部署策略一般是沉淀在运维同学的脑子里，或者在运维的平台和工具里的那这些工具，这些策略的能力要被应用到整个流水线上。

可描述：

研发模式的具象化表达
发布流程一致性
最佳实践可以快速复制

所以整个部署过程中，跟运维发布平台做一个非常强的一个偶合。另外一个重要的一点，就是在运维上，会有很多安全性的东西，比如有安全性的一些loti，或者安全策略这些东西，这些东西是非常敏感的，不能承载在流水线或者代码中，这些东西也会通过因为商务平台去做一个管控，所以在这情况下，通过这些手段让流水线跟官道流水线地方，水应该是什么样子的呢？

首先应该是一个可描述的，在第一堂课也说过此事，问题就是流水线本身是可以像描述一段代码录一句话一样去描述描述的，首先是一个研发模式的一个表达，一个具象化的比如看到这些，就知道是什么样子，然后通过流水线可以保证整个发布流程是一致的，不会出现偏差前面的一致性的问题，第三个其实软件我可以把实践快速的去复制，只要用同一条流水线的模板，就可以用同一个实践。

第二个应该是可观测的，整个发不了邮件，本身发到哪，发了什么，中间有什么问题，成功失败，是可观测的，并且观测是可以跟监控的数据，一起去观测。这样就可以导致我整个发布过程是有保障的，可以看得到，第三个整个过程应该是自动化的，本身过程是自动化的。

构建完之后，并不需要人去栽到验证阶段，再触发起来，而是整个过程是自动流转的，整个流程是建立在一个工具的一个基础上，而不是通过人去把它落地下去的。

所以自动化是可执行，可运行的。简单的转变一下思维的方式，如果不是从左到右来去看，而是从右到左来去看，有一种中泰思维，然后来去想，最右边是需要一个稳定可预期的一个系统。这时就要去找到一个稳定可预期的一个软件的一个制品版本。然后另外一个要找到相应的一致性的一个环境，这时再去做成一些不熟不熟的时候，符合刚才说的四个原则，前面无论是持续集成也好，持续测试也好，无非就是要确定的软件制品，然后去把这件事能够给四个原则给部署上去，所有的能力，或者这些活动也好，都是为了最终的目标来去服务的。如果这样就很好很简单的去理解，处于爬坡流水线。刚才提到了持续发布流水线，是可以帮助很好的把流程在工地上能够快速落地，能够快速的复制出去，可以去看一些具体的一些例子。

二、具体示例介绍

这是一个流水线一个模板化的一个描述。给了两个例子，首先是一个模板，就是流水线，这是营销去做的一个例子，会在一个团队，或者一个公司层面，会有一些认为最佳实践的模板，比如Java的一个发布的一个模板，应该首先应该有代码扫描的有测试，然后是构建，然后是部署。这是一个比较好的一个模板。可以自定义更多的一个模板要求。同时有了模板之后，就可以在整个团队用第二个，可能会有一些统一的一个环境变量，比如在运行，在发布中间会注入一些SJK账号的一些东西，那些东西，是不希望它在代码中明文去存储的，但是会动画片存住下去，那可以通过第二种，这样的方式跟方法打通，假设把develop. Test. Local 作为自己的一半管理平台，可以通过此方式给做一个很好的一个集成，可以在平台里去定义一些敏感的东西，或者是一些公共的一些东西，在每一个流水线的步骤里面去应用，就达到了全局层面的一个复用的能力，然后流水线本身应该是可以具备观测性的，比如首先要能知道当下的整个现在情况，最新的是不是有完成的，还是在举行，有没有连续的，失败的情况，这连续失败情况需要需要去关注的，然后第二个流水线，就是可以看到，在一个feature从开发到集成到发布的整个阶段是什么样子的，中间是不是存在一些问题，比如像流水线：

从开发完到计生之间有很长的时间等待，想知道中间发生了什么，可以研究一下。另外发现最后发布失败了，但失败之后可能到现在没有人去处理，那需要去看一下发生了什么，基于这些现有的一些工具，是对于营销的一个看法和营销代码，包括阿里云里，构建了一个完整的一个在web的一个研发的一个模式。

就是从需求的角度来说，达到相应的需求，然后再任务看板里拿到相应任务开发任务，就可以做相应的一些代码的一些push。之后在代码的层面可以做些。像一些鉴定和安全扫描完了之后，再可以做相应一些构建，然后提成，然后验证，最后上线这样的一个过程。

当然，如图看上去其实是比较常见的一个资讯发布的一个流程，这里其实可以看一下，右上角里有三个字，提出来的一个愿景，愿景是什么呢？就是希望一个小时的发布前置市场，就是从代码提交到发布到生产环境，希望一个小时能够完成。那另外一个，就是希望每天至少能够做一次可发布的一个版本。

然后针对团队每个应用每周至少能够发布一次。那这样的方式，一个愿景，能够帮助去发现整个在集成发布过程当中的一些问题，为什么不能一个小时做到，哪些原因导致了损失的，这时就可以找到影响发布的一个问题的一个关键所在，这是一个目标，现状跟目标之间是有一段距离，距离就是 gap，那这里相应的APP里就是要去解。所以提出是给大家一个愿景，一个目标，然后帮助去发现相一些问题，当然也可以去参考一下，比如其他的一些标准。其实是向军营销的口大投资，可能也不太一样，而且 flow 也可以跟监控来去打通，原有资产对现有的一些资产，也能够复用，另外一个，比如像 web 应用，也就是常见的一个服务端。另外一个，就是手相前端通过辅导直接把做一个简单的一个分享。