基于 CI/CD 的 DevOps 思想

目录

DevOps 思想

DevOps 是一组用于促进开发、测试以及运维人员之间协作的过程、方法和系统的统称。

• 开发：研发部门。
• 测试：测试部门，或称质量保证部门。
• 运维：服务部门。

DevOps 提倡通过一系列的技术和工具降低开发、测试以及运维人员之间的隔阂，实现从开发、到测试、再到最终部署的全流程自动化，从而达到开发、测试、运维一体化。通过将 DevOps 的理念引入到整个生产系统的流程中来，能够显著提升软件的开发效率，缩短软件交付的周期，更加适应当今快速发展的互联网时代。

一个 DevOps 系统应该具备以下 8 点要求：

1. 环境一致性：在本地开发出来的功能，无论在什么环境下部署都应该能得到一致的结果。
2. 代码自动检查：为了尽早发现问题，每一次代码提交后，系统都应该自动对代码进行检查，及早发现潜在的问题，并运行自动化测试。
3. 持续集成：每次代码提交后系统可以自动进行代码的编译和打包，无需运维人员手动进行。
4. 持续部署：代码集成完毕后，系统可以自动将运行环境中的旧版本应用更新成新版本的应用并且整个过程中不会让系统不可用。
5. 持续反馈：在代码自动检查、持续集成、持续部署的过程中，一旦出现问题，要能及时将问题反馈给开发人员以及运维人员。开发和运维人员收到反馈后对问题及时进行修复。
6. 快速回滚：当发现本次部署的版本出现问题时，系统应能快速回退到上一个可用版本。
7. 弹性伸缩：当某个服务访问量增大时，系统应可以对这个服务快速进行扩容，保证用户的访问。当访问量回归正常时，系统能将扩容的资源释放回去，实现根据访问情况对系统进行弹性伸缩。
8. 可视化运维：提供可视化的页面，可实时监控应用、集群、硬件的各种状态。

CI/CD

《敏捷宣言》中最早的一项原则可以追溯到 2001 年 —— “我们的首要任务是通过尽早并持续交付有价值的软件来满足客户”。

敏捷软件开发的成功在很大程度上取决于团队能否迅速向最终用户推出功能并结合最终用户的反馈不断改进软件。周期越短，用户满意度就越高。所谓持续（CONTINUOUS）是敏捷开发模式（Agile development model）的关键，简而言之就是 “小步快跑”，快速验证市场需求。CI/CD 系统，或称之为 DevOps Pipeline（管道）就是为了实现这一崇高愿景。

通常的，软件系统工程学定义了以下软件开发阶段：

1. 需求分析。
2. 可行性分析。
3. 总体设计。
4. 详细设计。
5. 编码实现。
6. 测试。
7. 部署运维。

相对的，在一个标准的 CI/CD 系统中，关于代码的生产管理主要抽象为以下 4 个流程：

1. 持续集成：代码实现、提交代码、代码规范检查、代码审阅、编译源代码、单元测试、功能测试、漏洞扫描、最终合并至代码仓库。
2. 持续交付：从代码仓库拉取代码，并完成可交付软件镜像/包的构建并上传至软件镜像/包仓库。同时，根据需要将新版本的代码部署到 QA 或预生产环境中。
3. 持续测试：由 QA 团队完成测试用例设计、集成测试、回归测试、性能测试、压力测试。
4. 持续部署：面向生成环境的部署实施，将产品交付给最终客户。

注 1：理想的状态下，所有的测试内容都应该在 CI 阶段自动化完成，但实际上测试是一门复杂的学科，QA（质量保证）团队的人工介入是更加现实且可靠的做法，所以 CT 是一个必要的检验流程。
注 2：我更加愿意使用 “受控部署” 来描述 “持续部署”。在实践中证明，全自动的部署方式是具有业务风险的，所以 “受控” 的真谛在于：基于持续交付、持续测试的 “认证” 前提，由人工最终确定部署细节并完成实施动作。
注 3：持续交付和持续部署经常被混淆，但这是两回事。马丁·福勒（Martin Fowler）对此的描述如下：

“持续部署意味着每项变更都将贯穿整个流程并自动投入生产，从而导致每天进行许多生产部署。持续交付只是意味着您能够进行频繁的部署，但可能会选择不进行部署，通常是由于企业偏向于降低部署速度。为了进行持续部署，您必须进行持续交付。”

持续集成（CONTINUOUS INTEGRATION）

持续集成的核心需求是：从代码的角度出发，让代码生成的流程兼具开发效率和代码质量保证的优势。

• CI 系统由代码版本控制工具（e.g. git）和代码托管平台（e.g. Gitlab、Github）组成。
• CI 流程需要完成：代码实现、提交代码、代码规范检查、代码审阅、编译源代码、单元测试、功能测试、漏洞扫描、最终合并至代码仓库。

持续交付（CONTINUOUS DELIVERY）

代码从被开发出来到最终的生产上线，需要经历多种不同的 QA 环境，例如：自动化集成测试运行环境、预生产环境，有些时候甚至验证软件在具有特定条件的环境中的运行情况，例如：x86、ARM 架构。显然，持续交付不是一件省心的事情，直到容器技术以及基于容器的自动化编排技术的成熟，持续交付才被证明为可行的。

持续交付的核心需求是：为随时需要完成的最终部署最好准备，为持续测试做好准备。持续交付流程在 CI 流程后触发，自动地从代码仓库拉取最新的或指定版本的代码，构建出软件镜像并上传至镜像仓库，以备部署使用。同时，根据需要，可以自动化的将指定版本的软件部署部署到 QA 环境。

持续测试（CONTINUOUS TESTING）

复杂软件系统的测试工作往往也是复杂的，优秀的 QA 团队需要与研发团队同步理解客户的需求、以及功能实现的效果，与研发团队协作完成测试用例的设计。

DevOps 最具价值的优势之一就是可以更频繁地进行自动化测试，可以在软件开发过程中尽可能早、尽可能快地持续关注检测缺陷、错误和 Bug，而又不会给开发人员或运维人员增加更多的手动工作。所以，云原生时代的优秀 QA 团队除了需要具备上述提到的业务理解能力之外，还应该具备 DevTest 的能力。显然，这是一个发展的过程，目前 QA 环节中的集成测试、回归测试、性能测试、压力测试依然仰仗着人工完成。

无论是通过自动或手动来完成 QA 工作，持续测试的核心需求始终都是：为后续的持续部署设定严格的门禁。

• 持续集成阶段：自动化完成单元测试、功能测试、API 测试。
• 持续测试阶段：手动完成集成测试、回归测试、性能测试、压力测试。

持续部署（CONTINUOUS DEPLOYMENT）

因为产品部署是直接面向客户的，且与客户的 IT 系统关联紧密，所以持续部署更多需要考虑的是 “可控性”。以 ToB 部署为例，需要：适应客户 IT 系统条件、提供软件镜像、提供离线部署依赖安装包、提供自动化安装/升降级/扩缩容程序、提供问题反馈的工单系统等。

CI/CD 系统组成

CI/CD 系统主要由 7 部分组成。

1. 代码托管平台 Gitlab。
2. 代码质量检测平台 SonarQube 。
3. 代码审查平台 Gerrit。
4. DevOps 管道平台 Jenkins。
5. 容器技术 Docker。
6. 镜像仓库 Harbor。
7. 容器集群管理系统 Kubernetes 。

CI/CD 流水线示例

1. 开发人员在本地开发并验证好功能后，将代码提交到代码仓库。
2. 通过事先配置好的 Webhook 通知方式，当开发人员提交完代码后，部署在云端的持续集成工具 Jenkins 会实时感知，并从代码仓库中获取最新的代码。
3. 获取到最新代码后，Jenkins 会启动测试平台 SonarQube 对最新的代码进行代码检查以及执行单元测试，执行完成后在 SonarQube 平台上生成测试报告。如果测试没通过，则以邮件的方式通知研发人员进行修改，终止整个流程。若测试通过，将结果反馈给 Jenkins 并进行下一步。
4. 代码检查以及单元测试通过后，Jenkins 会将代码发送到持续集成服务器中，在服务器上对代码进行编译、构建然后打包成能在容器环境上运行的镜像文件。如果中间有步骤出现问题，则通过邮件的方式通知开发人员和运维人员进行处理，并终止整个流程。
5. 将镜像文件上传到私有镜像仓库 Harbor 中保存。
6. 镜像上传完成后，Jenkins 会启动持续交付服务器，对云环境中运行的应用进行版本更新，整个更新过程会确保服务的访问不中断。持续交付服务器会将最新的镜像文件拉取到 Kubernetes 集群中，并采用逐步替换容器的方式进行对应用进行更新，在服务不中断的前提下完成更新。