持续集成：部署发布篇

随时随地发布软件

提交出用户满意的、高质量的工作软件是研发的终极目标，能够随时随地提供可工作的软件，不仅减轻“终极构建”发行噩梦在开发同学心中的阴影，也有助于项目经理把控版本发布节奏。

那么，持续部署和发布在持续集成中应该如何执行呢？

典型的部署工作由以下部分组成：

1）为库中的资产打上标签

2）得到干净的环境，避免不当的假定

3）直接从版本控制库中取出软件，生成构建版并为他提供标签，在目标机器上安装

5）在生产环境的克隆环境中成功地执行所有级别测试

6）创建构建反馈报告

7）可以利用版本控制库中的标签回滚构建版

通过上述步骤，可通过执行完全自动化的构建，包括编译、所有测试、审查、打包和部署，在所有已知环境随时发布能工作的软件。

为库中资产打标签

创建版本控制库的标签有利于标识并追踪资产，清楚地说明一组文件是在一起的。标签使我们可追踪一组文件的历史，而不仅仅是单个文件历史。

通过及时创建快照，可以使新版本代码的过渡更顺利。打标签可以采取不同风格，最简单的命名格式为：

主版本号“_”(或“.”)次版本号（如2_89 、2.89）

得到干净的环境

在一个环境中试图部署软件，发现环境中操作系统、数据库或服务器版本不一样，是一件令人很头疼的事情。

想要得到一个干净的环境要删除并重装软件、执行脚本并配置值，确保环境按照期望地去工作。删除机器上所有软件后重新安装的内容有：

1）操作系统

2）操作系统的配置，网络连接、用户、防火墙等

3）软件所需的服务组件，应用服务器、数据库服务器、消息服务器等

4）服务器配置

5）第三方工具

6）定制的软件

有可能只需要删除上述其中一个内容，删除并重装多少内容取决于对风险级别的要求。这个过程自动化程度越高越好。

每个构建版本打标签

为每一个构建版创建唯一的标识符，即“构建版标签”，为二进制制品打上标签：

1）版本控制库中的代码需要一个标签

2）代码的构建动作需要一个标签

这些构建标签让大家知道在特定环境下使用了什么版本的代码，通过这些构建标签，缺陷、功能和新需求都可以用这一份代码作为依据。

执行所有测试

在持续构建过程中，可能只需要执行部分测试，但在打包部署前必须执行所有测试并通过。包括：单元测试、组件测试、系统测试、功能测试、性能测试、负载测试及其他类型测试，确保软件已准备好交付。

除了自动化测试外，还需要由人来进行测试，因为产品的最终用户是人。

所有测试审查执行完成后，需要生成自动化构建的反馈信息表，包括本次构建版中哪些文件不同、修复了哪些缺陷、实现了哪些功能，让大家理解将要发布的构建版的确切情况。

需要有的报告应当有：文件差异报告、缺陷修复报告等，这些报告可能对QA团队有所帮助。

可回滚构建过程

能够“撤销”部署是有效开发中的重要一环。出现问题的可能性总是存在的，所以要利用构建标签来回滚那些不该提交到版本控制库的变更。

实践自检

1）系统拥有回滚能力吗？

2）对候选发行版是否有完整自动化+人工测试流程？

3）是否能为不同环境配置部署，在克隆用户环境的干净计算机正确安装并运行软件？

4）部署发布是否能提供反馈报告？是否有缺陷追踪系统？

5）是否能从版本控制库中取出所有软件资产并构建部署？

转载于:https://juejin.im/post/5cbf0920f265da039a3d70df