DevOps落地笔记-14|部署流水线：打造一站式部署的关键平台

上一课时我主要介绍了实现自动化测试的范围、流程和结构图，自动化测试是持续集成实践不可或缺的一部分，从而使得软件向高效率和高质量迈进了一大步。持续集成主要关注的是代码是否可以编译成功、是否可以通过单元测试和验收测试等。但持续集成并不能实现软件包向测试环境和生产环境部署的要求。如果软件包不能很快的部署到测试环境和类生产环境，就导致开发人员不能及时的收到反馈，就会使软件存在更多的缺陷。今天介绍的内容——部署流水线，就是搭建一套从开发到测试，到运维的流水线，能够实现一键式的将软件部署到生产环境。

什么是部署流水线？

软件开发过程是一个将客户或用户的想法变成一个真实可用的特性的过程。部署流水线是这个过程中的一部分，是指软件从版本控制库到用户手中这一过程自动化的展现形式。这一过程包括编译构建、代码检查、上传制品库、测试和部署等，并且这些阶段的执行都应该是自动执行的。自动化带来的好处是这个流程变得更快、可重复且更加可靠。

部署流水线主要包含下面几个阶段：

& 提交阶段，代码提交后会运行代码编译、自动化单元测试以及对代码进行动静态扫描；

& 自动化测试阶段，主要是从功能性和非功能性方面验证系统是否可用，并且满足用户需求；

& 手工测试阶段，主要是用户验收测试，用于验证系统是否为用户提供了价值；

**发布阶段，**将软件交付给用户，交付方式有多种，可以是独立部署的方式，也可以是 SaaS 服务的方式。

部署流水线包含的很多阶段我们之前的课程都有提到，比如提交检查、自动化测试等，和部署相关的内容涉及较少，这部分内容是本课时的一个重点。

部署流水线相关实践

为了更好地发挥部署流水线的作用，在实施部署流水线的时候要遵循以下几个准则：

一包到底

一包到底是之前课时的内容，就是将软件从源代码编译构建出一个部署包，在后续的流程中都统一使用这一个部署包。这样做的好处有以下两点。

& 减少了编译时间：每次编译都需要花费时间，并且占用编译机的资源，如果代码库比较大重复编译将是一场灾难。

& 保证部署包的一致性：因为在各个阶级进行测试的部署包都是同一个，这样可以保证部署到生产环境中的部署包与前面测试阶段验证过的部署包是完全一样的。

那么如何保证每次部署的包都是同一个呢？在之前的流水线中，每次生成部署包的同时也会生成一个 md5 值，并在后续每次部署时利用这个 md5 值对部署包进行验证。这也是大多数企业中部署时采用的一种方法。

另外，对于每次构建出的部署包都需要存放到专门的制品库中，如 Jfrog Artifactory。这一步骤可以集成到持续集成流水线中，上传制品库时同时也会携带该部署包的属性，如：代码库、版本号、CommitId。Jfrog Artifactory 支持对制品打标签，可以在后续的测试阶段将测试结果以标签的形式打到制品上，作为是否进阶到下一个阶段的判断条件。

相同的部署方式

使用相同的流水线、相同的部署方式部署任意一套环境，包括生产环境！ 这样既能对构建和部署流程进行有效测试，提高部署流水线的稳定性和健壮性。又能保证不同环境的部署过程是一致的。当部署的服务出现问题时，可以排除部署脚本导致的因素。

实际情况中，每套环境有很多不同之处，比如机器的 IP 会不同，操作系统和中间件的配置不同等。不同的环境信息并不意味着就要为每套环境都准备一套部署脚本，我们可以采用将部署脚本与配置信息分离的方法。在之前的“环境管理”课时中提到，将部署脚本作为模板存储在 Git 代码库中，将每个环境不同的配置信息存储在 CMDB 中，就能实现通过一套部署脚本部署所有环境。

采用相同的部署方式是降低发布风险的方法之一。因为不管是测试环境、还是生产环境都是相同的部署方式，在向生产环境部署之前，已经在测试环境部署了 n 次了，部署脚本已经非常健壮，能够大大降低向生产环境部署的风险。

对部署冒烟测试

在应用程序部署完成后，应该有相应的脚本对应用程序进行冒烟测试，以确保应用程序启动并运行了。这个测试可以很简单，比如调用接口检查是否能正常返回。如果要检查依赖的服务，比如数据库和缓存服务等，可以调用从依赖服务获取数据的接口，结果可以是空，只要能确保连接是正常的即可。

冒烟测试又称为部署测试，它是环境部署完成并交付使用的有效验证方法。如果服务不可用，也能知道是什么原因导致的不可用：是服务本身还是依赖服务？这对排除应用程序无法正常运行问题也很有帮助。

如何实现部署流水线

下面介绍一下如何实现部署流水线。下图是部署流水线的结构图，该图也反映了真实的软件交付过程。起点是开发人员将代码提交到版本控制系统中，终点是将软件部署到生产环境交付给用户。在上面介绍的部署流水线的相关实践，在该图中都有所体现。

& 版本控制系统和制品库是源代码和制品的单一可信数据源。制品库中的部署包只能通过版本控制系统中的源代码编译构建产出，并上传到制品库。后面测试环境和生产环境需要的部署包都来自同一个制品库，保证了部署包的唯一性。

& 测试环境和生产环境都是通过部署平台统一部署，测试环境可以由测试人员自服务部署，生产环境可以由运维人员一键部署。

& 不管是测试环境还是生产环境，当软件部署完成后，通过冒烟测试验证服务是否正常启动。

部署流水线中的很多阶段在之前的课时中都有涉及，提交阶段的编译打包、代码扫描、自动化测试、环境管理等，这里就不做太多阐述。我主要介绍一下自动化部署和发布到生产环境相关的内容。如下图所示，自动化部署平台提供一键部署的功能。用户只需要选择在哪个环境、使用哪个软件版本，采用什么样的部署策略即可。

自动化部署平台

自动化部署平台是部署流水线中的重要组件，通过封装统一的部署流程，提供易用的用户界面，对外提供统一的软件部署的能力。部署平台提供一套部署脚本，屏蔽测试环境和生产环境的差异。在进行自动化部署时，只需要提供部署的软件版本以及要部署的目标环境，采用什么样的部署策略（只对生产环境有效），点击“开始”按钮，所有的部署过程都是自动化的。

关于“部署软件”和“发布软件”，很多人认为它们是一样的，他们的区别在于 “发布”是一个业务行为。部署软件是将软件部署到生产环境中，但部署的服务是否发布给用户是由业务决定的。目前很多企业中，部署和发布是相等的，软件部署到生产环境就直接发布给用户使用了。但有些功能这样做会有问题，特别是跟时间、位置相关的功能。比如促销活动，只能在固定的时间范围内有效。只不过目前的发布并不是由业务人员手动点击发布按钮触发，而是由程序自动化的触发。

部署策略

部署策略是针对生产环境的，因为生产环境是用户使用的真实环境，部署失败可能会对用户造成严重影响。因此，在部署生产环境时要采取低风险、零停机的部署方式。目前常用的方式有蓝绿部署、金丝雀发布和特性开关等方式。

& 蓝绿部署：蓝绿部署是指有两套相同的生产环境，一套叫蓝环境，一套叫绿环境。如上图中两种不同的颜色。假如当前用户正在使用作为生产环境的蓝环境。如果要发布一个新版本，先把该版本发布到绿环境中，并在绿环境中进行冒烟测试来检查服务是否可以正常工作。当一切准备就绪后，将用户引导到绿环境即可完成新版本的升级。如果此时出现问题，再将用户切换回之前的蓝环境即可完成回滚。这样不会对用户造成太大的影响。

& 金丝雀发布：金丝雀发布是指将新版本的服务部署到生产环境的一部分服务器中，如上图所示。通过一小撮用户试用的方式，可以快速得到反馈，及时的发现新版本中存在的问题，而不会影响大部分用户。如果新版本出现问题，只要不把流量引导到有问题的新版本上就行。另外，金丝雀发布的方式可以用来做 A/B 测试，将一部分用户引导至新版本和旧版本上，分别分析不同版本对用户、收入等指标的差异。

& 特性开关：特性开关是一种轻松开启和关闭功能的方式。当软件部署到生产环境中，此时该功能并未对用户开放，只有通过特性开关启用该功能时，用户才能使用该功能。如果此时发现问题，只需要将开关关闭即可。特性开关实现也比较简单，可以在代码中通过 if-else 的方式控制代码执行的路径。

总结

本课时介绍了使用部署流水线实现一键部署软件到测试环境及生产环境，通过自动化的方式完成软件部署的最后一公里。部署流水线并不是指用于部署，而是从代码提交到代码库到最终部署到生产环境的整个过程，包含了前面提到的代码扫描、自动化测试和环境管理等阶段。为了更好地实施部署流水线，介绍了几个关键的实践以及通过自动化部署平台完成部署这个阶段的操作，最后介绍了零停机发布到生产环境的几种部署策略，实现低风险发布。部署流水线是 CICD 的重要组成部分，也是实现持续部署的重要环节。这一部分在企业里一般属于运维侧平台，随着 DevOps 的普及，开发和运维的界限越来越模糊，开发人员可以利用运维开发的部署平台自服务，根据业务需求随时发布软件到生产环境。