智能运维：浅谈持续集成( CI)、持续交付(CD) 和软件测试

导读：浅谈CI/CD 和软件测试

知其然，知其所以然。相较于DevOps而言，CI/CD是一个相对具象的概念。在IT 企业中，CI/CD的应用愈加广泛，成为推动软件研发活动的重要基础设施服务，同时推动DevOps 模式的实际落地。

什么是CI/CD

在实践CI/CD 相关内容之前，我们有必要先认识下什么是CI/CD。

一般传统或者狭义、普遍的CI/CD，是指持续集成（Continuous Integration，CI）和持续交付（Continuous Delivery，CD）。而更加广义、全面的理解，是指持续集成（Continuous Integration，CI）、持续测试（Continuous Testing，CT）、持续交付（Continuous Delivery，CD）和持续部署（Continuous Deployment，CD）四个方面。通常，一个软件开发的流水线如下图所示。

?Design：这一阶段完成软件开发的需求分析和设计。

?Develop：这一阶段完成软件开发的功能代码，一个最佳实践是采用测试驱动开发（TDD）的方法，测试代码和功能代码的编写同时

进行。需要注意的是，在Develop 阶段也会运行单元测试和其他

小型测试。

?Test：这一阶段完成软件的各项大型或专项测试，比如界面测试、API 测试、性能测试和系统测试等。

?Release：这一阶段完成软件产品的发布，并交付给用户使用。

持续集成（Continuous Integration）

随着敏捷开发的发展，持续集成在软件项目活动中也日益成为主流。顾名思义，持续集成是指每日频繁地（比如一天多次）将代码集成到主干分支中。强调通过集成和测试的速度，快速给出一个集成的结果（是失败还是成功），在代码集成之前，必须先通过自动化测试验证，只要有一个测试用例失败，就不能集成。

Martin Fowler 说过，“持续集成并不能消除Bug，而是让它们非常容易被发现和改正”。这也正是持续集成的真谛所在。

敏捷开发的核心是指整个软件开发活动被划分成一系列短的迭代过程，每个迭代完成一定数量的功能，迭代周期应该尽量短。在软件开发需求已经确定的情况下，迭代应该由测试驱动开发（TDD）和集成反馈来驱动。只有这样，才能为质量持续改进奠定一个良好的基础。

持续集成是和单元测试结合在一起的，也就意味着，持续集成和单元测试需要并行工作。持续集成一般由代码每次git push/review 触发。先签入代码就先看到构建结果，后签入，则要排在后面。这就要求构建时间不能太长，否则在构建时容易引起混乱，很难知道是谁的代码破坏了集成，导致很难定位问题。

可以说，持续集成是敏捷开发的重要基础环节，没有持续集成，所谓的敏捷开发便失去了赖以生存的土壤，其实施效果也会大打折扣。持续集成是一种软件开发实践，团队成员频繁集成他们开发的代码，每次集成都会经过自动构建——自动测试的验证，以尽快发现集成错误。使用这种方法可以显著减少集成引起的问题，并加快团队合作开发软件的速度。（1）持续集成过程

持续集成的工作阶段比较明确，主要有三个大的阶段：持续集成准备阶段、持续集成使用阶段和持续集成测试阶段。

持续集成准备阶段的工作主要包括：

?通过代码评审系统（比如Gerrit），实现代码审查和集成反馈。?通过版本控制系统（比如Git或GitLab）建立源码仓库。

?通过构建工具运行相关构建和测试（比如Python 项目的Tox 和Pytest）。

?通过CI 系统（比如Jenkins）建立Job，将版本控制和构建工具整合，并设置构建触发条件。

持续集成使用阶段的工作主要包括：

?开发人员向代码评审系统（比如Gerrit）提交代码。

?通过CI 系统监听代码的提交，运行单元测试，反馈集成结果。?通过构建工具对代码进行编译、打包和部署。

?通过版本控制工具实现版本控制与管理。

持续集成测试阶段的工作主要是，CI 系统根据集成结果进行不同操作，如果成功，则将代码合并到主分支；如果失败，则反馈给开发人员修改重新提交。

从中我们可以看到，持续集成涉及的主要工具类别包括：

?版本控制工具——实现源代码管理、版本控制。

?构建工具——实现代码的自动化编译、打包等，这是持续集成的核心工具。

?测试工具——实现代码的自动化测试，以及大型测试或专项测试。?CI 系统——整合版本控制、构建工作和测试工作，实现持续集成。（2）持续集成的好处

主要有以下几点：

?易于定位错误。比如当持续集成失败时，说明新提交的代码引起了错误，这样也很容易知道是谁犯了错误，可以找谁来讨论。

?提高团队的开发信心。虽然整个系统还不是那么可用，但至少可以看到功能已经在一点点被集成了。

?提高对进度的控制和把握。这点非常明显，如果每天都在集成，当然每天都可以看到哪些功能可以使用，哪些功能还没有实现。如果你是开发人员，则不用为在每日Scrum 晨会时说自己完成了多少开发而烦恼；而如果你是Scrum Master，那么也不用再烦恼开发人员说完成了代码的40%到底是个什么概念。

?有助于代码开发的质量评估。比如从开发质量的评估图表中，找出经常出错的测试和源码等。

?与测试工具结合，做到每次提交都进行测试。

?快速发现错误。每完成一点开发，就提交评测、代码审查，可以快速发现错误，及时修复，越尽早解决，成本越低。

持续测试（Continuous Testing）

持续测试作为软件持续集成中的重要组成部分，为软件项目的成功提供了保证软件质量持续改进的重要手段。在持续集成中，更多的是运行小型的单元测试，因此，关于其他测试将在后续章节中阐述。

持续测试是指开发人员提交代码后自动运行相关单元测试，给出测试结果的反馈；如果失败，则会在测试结果的详情页面中输出错误提示。有了持续测试，我们才能实现真正的测试驱动开发（TDD）。举一个例子，当开发人员向代码评审系统提交了代码后，Jenkins hooks 监听到

有代码提交，自动运行单元测试，然后在页面视图上显示测试的结果；如果测试失败，开发人员需要重新修改并再次提交测试，直至成功。这也需要开发人员在编写功能代码时，同时编写测试代码，这样几乎能够在问题产生之时就将其发现。不经常运行测试通常就不怎么有效，因为从产生缺陷到发现该缺陷相隔时间很长，但持续地（即每一次代码改变时）运行测试能确保快速地发现症结。

持续测试应当输出测试报告，报告是将持续集成的运行情况以适当的形式展现给相关人员的基本方式。报告是持续集成的晴雨表，所以它必须直观、易懂，比如开发人员从错误日志中找到代码出错的位置和原因；QA 测试人员发现测试的覆盖率和执行情况；管理人员从持续集成通过率的趋势中了解到项目的进度和质量。

持续交付（Continuous Delivery）

持续交付和持续部署是两个非常容易混淆的概念。持续交付指的是频繁地将软件的新版本交付给QA 测试团队或者运营团队，如果评审通过，代码就进入发布、生产阶段。

为了更加符合国内软件行业的实际情况，我在这里将QA 和测试统称为“QA 测试”。持续交付可以看作是持续集成、持续测试的延续，它强调的是不管怎么更新，软件是随时随地可以交付的。通过严格的自动化测试，可以确保软件开发的质量和进度。因为通过完全的自动化过程

把每个变更自动提交到测试环境中，所以当功能开发完成时，就有信心只需要点击一次按钮就能保证发布和部署应用的质量。

（1）选择持续交付工具集

在没有制定出工作流程时，便考虑选择持续交付工具集，是最不重要的决策。实际上，在设计好工作流程和业务流程之后再选择相匹配的工具集即可。考虑到满足实际业务和工作流程的情况，开发一些诸如Shell、Python 等脚本程序是非常理性的做法。

更重要的是，无论是CI 还是CT、CD 等，都可以使用众多的开源工具，这样做没有被锁定的风险，可以自由切换等。

（2）持续交付的角色和方式

产品持续交付的角色应由QA 测试人员来担任，开发人员也需要参与到产品的某一轮系统测试中，并随时准备Bug 审查和Bug 修复。最后，由QA 测试人员根据具体的产品缺陷、质量情况等做出产品是否适合面向用户交付、发布的决定。

持续交付的目标不是要消灭缺陷，而是要规范开发和测试的流程，从根源上提高软件质量。总之，持续集成、持续测试、持续交付和持续部署的核心就是让不间断的“密集型、高强度、信息及时反馈的持续性改进”成为提高软件产品质量的驱动力。

目前，持续交付的方式一般有：

?源代码交付——需要将源代码下载到所需要的环境中，如Python 的py、Java 的java等程序文件。但这些文件都不是标准的软件包，不利于集中管理和运行。

?Linux 标准包交付——通过Linux deb 或者RPM 对项目的依赖进行管理。这种方式相对更加规范和科学，但仍然需要解决包冲突问题。同时，这种方式会经常因服务器环境差异、构建环境初始化失败等问题导致无法部署Linux 标准包。

?虚拟机镜像交付——在虚拟机中安装测试软件产品成功后，直接将该虚拟机镜像（比如VMware 的vmdk、VirtualBox 的ova、OpenStack 的qcow2 等镜像）进行交付、发布。显然，这种方式部署成功率接近100%，而且隔离性好。但存在着虚拟机镜像对服务器资源的消耗，同时容量较大、不够灵活等问题。

?Docker 镜像交付——这种方式是对虚拟机镜像交付的重大改进，在保证系统隔离的同时，Docker 镜像对服务器的资源消耗更低、更加轻量。这种交付方式将成为主流趋势。

持续部署（Continuous Deployment）

持续部署是持续交付的后续阶段，也是整个CI/CD环节中的最后一环，指的是软件通过测试后自动部署到生产环境中。持续部署的目标是软件在任何时刻都是可部署的，可进入生产阶段，发布给用户使用。持续部署的前提是能够自动化完成集成、测试和交付等。它与持续交付的区别是，持续交付是将软件部署到线上环境中，使用的是手动方式；而持

续部署强调的是自动化。换言之，持续部署是持续交付的更高阶段，所有通过了测试验证的软件都自动部署到生产环境中。如果没有制度的约束或其他条件的影响，团队都应该以持续部署为目标，如下图所示。

CI/CD在软件研发测试中的应用

DevOps是一种工程文化、理论集，是一个抽象的概念；而其范畴下的CI/CD 则是它的具体实现和方法，是一种化抽象为形象的工具集、流程图。如果说DevOps 是云计算，那么CI/CD 就是计算、存储和网络，OpenStack 则是其具体实现平台。

软件项目的研发有两大难题：一是确定软件的需求，即确定目标；二是确定当前离目标还有多远，即确定剩余的工作量。后者是项目缺少可见性的问题。前者是持续性反馈的问题。比如来自用户需求的反馈、市场变化的反馈、项目研发测试过程的反馈等。

自动化是软件研发测试中的重要方式。持续集成最大的优点就是降低风险，提高项目研发过程的效率和质量，迎合互联网时代信息快速更新的规律。持续集成本身并不能帮助开发工程师和QA 工程师解决Bug，而是通过不断的测试和反馈来尽早地发现Bug，问题发现得越早，处理

问题的成本就越小，也越容易解决。由于无法证明通过了某次测试的代码永远无缺陷，因此，持续集成中的测试也就显得非常重要，好的测试能够更多、更快地发现当前版本中的错误。

根据持续集成的作业流，代码从提交到生产环境，整个过程分为以下几步。

提交（Commit）

开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交。

测试（第1轮）

整个CI 系统配置了代码仓库系统、Jenkins 系统和代码评审系统的触发器，只要提交代码就会运行自动化测试。一般这里的测试有如下几种。

?单元测试：针对函数或模块的测试。

?集成测试：针对整个软件的功能测试。

?代码风格测试：针对代码的编写风格进行测试，比如Python 的PEP 8 等。

?其他测试。

构建（Build）

通过第1轮测试后，代码就可以合并进主干分支，推送到私有代码仓库GitLab 系统中，进行下一阶段的构建了。

从开发人员提交本地代码，到测试通过，代码合并到分支里，提交就算完成了。此时，就需要进行构建进入第2轮测试。所谓构建，指的是将源码转换为可以运行的Linux 标准软件包，比如安装依赖、生成配置文件等，当然也可以构建成Docker 镜像。

测试（第2轮或多轮）

构建完成后，就要进行第2轮或多轮测试。总之，构建部署在测试之前。此阶段的测试最全面，投入资源最多，包括系统测试、功能/集成测试、性能测试等都会运行。需要强调的是，每一个更新点都必须测试到。如果测试的覆盖率不高，进入后面的部署和生产阶段后，很可能会出现严重的问题。

部署

通过多轮测试后，当前代码就是一个可以直接部署的稳定版本。将这个版本的所有文件打包存档（比如Fuel 的iso，或其他自研产品的iso、vmdk 乃至Docker 镜像等），发布到成品库服务器上。这方面的自动化部署工具有Ansible、Chef、Puppet 等。

回滚

一旦当前软件版本发生问题，就要回滚到上一次构建的版本，使用上一次构建并发布的版本。

CI/CD 很好地解决了代码从自动化编译打包、自动化构建部署、自动化测试到快速交付产品4个阶段。为此，需要做到：

?软件包尽量轻。为了保证代码在编译、打包、构建等阶段做到快速、轻量，应尽可能实现软件的模块化处理。典型的，如将OpenStack 的各个服务分别放在不同的Docker 镜像中。

?重视管理教育。在公司中，一个团队/部门里的工程师素质是良莠不齐的，不能让少数人影响到一群人、一个整体，仅靠自觉是完全

不够的，需要指导团队养成做事的好习惯。一个常见的问题就是开

发人员不写单元测试代码，影响到整个软件研发测试的质量和周期。构建产出物

构建工作主要产出两个东西：待测的软件包和应用系统（有的只有后者）。这两个产出物有所不同，前者是构建过程与环境无关，而且可重复，因此需要提供如yum、npm、gem 等软件包服务，让构建号和软件包号建立关联，便于回溯。

通过IaaS 云或Docker 容器将CI/CD 环境以微服务的方式运行，做到开箱即用。CI/CD是软件工程的一个重要实践，可以帮助我们更早地发现问题、解决问题，降低成本，同时大大减少交付、发布过程中的

不确定性，提高团队的生产效率。当然，CI/CD 与其他工具和方法也紧密相关。

每日构建和每日测试

每日构建（Daily Build）在反应速度上没有持续集成快，它更强调的是通过每天（通常是晚上）自动部署当天开发所累积的代码，并结合每日测试（Daily Test）方法进行自动化测试，用于评估和衡量项目的进度。持续集成特性决定了不可能在该阶段加入大量的测试，而每日构建则一般是在夜里执行的，那么这时就可以做更多的事情，比如代码质量检查、单元测试、测试覆盖率、集成测试等。每日构建会把当天所有的提交代码都一起做集成，而不像持续集成那样每提交一次代码就做一次集成。持续集成属于增量式构建，而每日构建则是一次完全构建。

每日构建是项目的心跳线。一般而言，通过每日构建我们可以看到项目的进度。比如今天有10个Bug 的修复代码都提交了，晚上进行自动部署并通过了自动化测试，第二天上班时通过查看邮件我们就可以发现每日构建成功了，那么项目就又往前迈了一大步，开发工作又有了具体的进展。

具体的，每日构建就是在每天晚上自动化部署一个OpenStack 环境（可以是all-in-one，也可以是multi-node），然后运行大型或专项测试，比如API 性能测试、API 接口测试、功能测试、部署测试等。