持续集成包括了编译、静态代码扫描、发布、自动化测试等过程。自动化测试对于保障软件质量和提高持续集成效率有着重要意义。

当前持续集成，已经扩展为持续交付，说到持续交付，我们不得不从最近两年如火如荼的 DevOps 谈起。DevOps 由 Development（开发）和 Operation（运维）两个单词组成，表达了鼓励开发和运维共同协作之意。一直以来 IT 企业中开发和运维部门之间存在着对立和很多影响软件发布效率的因素。Patrick Debois 作为一个具有丰富经验的软件开发人员和顾问，深刻意识到了这个问题。2009年 Patrick Debois 在O'Reilly Velocity 大会上关于 DevOps 的演讲获得了广泛关注，同年 Patrick 在比利时组织了 DevOps 日活动，并获得了巨大成功。在 Twitter 和大多数论坛中，DevOps 日被简称为 DevOps。DevOps 运动深受敏捷软件开发思想的影响，并引入了敏捷开发宣言和敏捷开发原则。因此如果谈到 DevOps 则会谈到敏捷开发，如果谈到敏捷开发则同样会谈到 DevOps。从我的敏捷项目实施和咨询经验看，敏捷开发和 DevOps 已经成为一对孪生兄弟，彼此很难离开而谈。

DevOps 是一种方法论，是一系列可以帮助开发者和运维人员在实现各自目标（Goal）的前提下，向自己的客户或用户交付最大化价值及最高质量成果的基本原则和实践。

开发者和运维人员之间最大的问题在于：虽然都是企业中大型 IT 部门不可或缺的，但他们有着截然不同的目标（Objective）。开发者和运维人员之间目标上的差异导致了混乱之墙（开发运维之墙）的存在。开发者（团队）与运维人员（团队）之间的混乱之墙大大阻碍了软件构建、测试、发布和运维的效率。

 

图 1 开发和运维的混乱墙

 

在传统开发周期中，开发团队将新发布的软件“隔墙扔给”运维人员，意味着自己的工作已经顺利完成。运维人员接手开发者的成果，准备开始进行部署。运维人员手工修改由开发者提供的部署脚本，当然更多时候这些脚本都是运维人员自己维护的。运维人员还需要手工修改配置文件，以反映生产环境的需求，而生产环境往往与开发或 QA 测试环境有很大差异。

就算最理想的情况，运维人员可能只是做了一些在另一个环境中已经做过的重复工作，而最糟糕的情况，可能会引入或发现新的 Bug。随后 IT 运维团队开始讨论他们所认为的，目前最正确的部署流程，然而由于开发和运维在脚本、配置、流程，甚至环境等方面的差异，基本上等同于要从零开始将所有工作重新执行一遍。

当然这一过程中不可避免会遇到问题，他们联系开发者希望进行排错。运维称开发者提供的代码本身有问题，开发者则回应称代码在自己的环境中一切正常，因此错误肯定源自运维端（运维人员）。

由于配置参数、文件位置，以及环境状态所执行的操作与自己的预期等因素存在较大差异，开发者甚至很难对这样的问题进行诊断。变更窗口留下的时间所剩无几，当然也没什么足够靠谱的方法将环境回滚至上一个正常状态。

那么原本应该一帆风顺的部署过程，为什么最后却变成了“救火队员”的应急演习？并且必须经历大量指责和错误才能最终让生产环境恢复可用状态？（这种情况经常发生，经常！）

DevOps 提供了解决方法。

图 2 敏捷与 DevOps

 

通过在共同的业务目的情境中让开发、测试和运维角色与流程变的一致，DevOps 有助于促进 IT 的统一。开发、测试和运维都需要明确，自己是统一业务流程的一分子。DevOps 思维确保了无论企业组织结构是怎样的，个体决策与行为需要尽力为统一的业务流程提供支持和促进作用。

DevOps 是一种融合了一系列基本原则和实践的方法论（并从这些实践中派生出了各种工具），意在帮助这些人员向着一个统一的共同目的努力：尽可能为公司提供更多价值。

 

图3 开发、测试和运维一体化

 

互联网时代下的现代企业，IT 交付至少需要达到以下目标：

• 快速迭代，灵活响应变化，高可用和适应性；
• 聚焦价值，持续改进；
• 用户体验至上，细节决定成败。

传统软件交付过程中，要求开发要“快”，要适应变化、敏捷、快速迭代、持续交付，而运维要“稳”，要求系统运行稳定，且具有高可靠性，这往往引起开发部门和运维部门的观念和工作冲突。

DevOps 是一种思想，它强调 IT 专业人员（开发人员，测试人员、运维人员）在应用和服务生命周期中的协作和沟通，强调整个组织的合作以及交付和基础设施变更的自动化，从而实现持续集成、持续部署和持续交付，DevOps 彰显开发、运维、测试、项目管理等技术人员工作的共同目标是“Enable the Business”（达成业务目标）。

典型的 DevOps 流程涵盖需求、计划、编码、构建、测试、发布、运营等多个环节，DevOps 通过增强团队间的协助和沟通，构建自动化持续交付流水线，达到快速交付和安全可控的目的。

DevOps 体系包括敏捷管理、持续交付、IT 服务管理、精益管理等思想和理论方法、及相关最佳实践，如 DoD、WIP（work in progress）、JIT(Just In Time)、One-piece-flow 等。

图 4 DevOps 理论体系

 

DevOps 落地过程中，最关键的也是最大的挑战是构建自动化持续交付流水线。自动化持续交付流水线涉及到代码管理（代码提交、代码静态分析、编译、构建、打包、单元测试等）、代码集成、部署、发布等环节，涉及到的工具主要包括代码管理工具、CI 等。

持续交付的关键是自动化，包括：

1. 自动化构建和打包。
2. 自动化持续集成。
3. 自动化测试。
4. 自动化部署。
5. 自动化生产部署。

持续交付的最佳实践包括：

1. 实现监控，实时监控应用，追踪应用的关键度量。

2. 实现回滚，这是最后的安全网。

3. 提取特异于环境的配置。

4. 执行金丝雀发布。

5. 记录审计信息。

6. 实现功能开关。

7. 基于云的基础架构。

   

 

图5 持续交付的最佳实践

 

在持续交付环境中，经常需要对环境（如生产环境和开发、测试环境）进行构建和拆除，因此使用云服务的环境可以提高环境使用的灵活性和敏捷性。

一般来说，在持续交付的环境中，软件产品构建、单元测试、集成测试和 UI 端的用户验收测试依次先后进行。

1. 从代码仓库中获得最新软件代码进行软件版本的编译和构建。
2. 编译构建成功后，通过 Jenkins、Hudson 等持续集成工具调用对应软件版本的单元测试脚本进行单元测试。
3. 单元测试通过后，通过 Jenkins、Hudson 等持续集成工具调用接口测试脚本进行接口集成测试。
4. 集成测试通过后，通过 Jenkins、Hudson 等持续集成工具调用 UI 自动化测试脚本（Selenium、Appium 等）进行自动化验收测试。

图6 自动化测试和 DevOps

 

持续集成的工具链通常包括：

• 版本控制工具（SVN、Git）
• 持续集成工具（Jenkins、Hudson)
• 编译构建工具（Maven、Gradle、NPM）
• 自动化测试工具（Junit、Rest-Assrued、Selenium、Appium）
• 等等。

我们在小明童鞋敏捷测试故事中将采用 Jenkins 进行持续集成，构建编译工具采用 Maven。不同类型的自动化测试在持续集成中所处的流程环节如图6所示。

从下面章节开始，我们正式从方法论和设计篇进入实战篇。如果您对下面使用的自动化测试脚本编写技术不太熟悉可以持续关注我发布的 Chat 文章或课程，也可以在读者圈中留言。我可以根据您的情况给出自动化测试脚本编写学习的相关建议和提供一些学习资料。

为了方便读者对敏捷测试过程的理解，我们的自动化测试演示分别选用的自动化测试技术如下：

• 单元测试工具选用 JUnit；
• 接口测试工具选用 Rest-Assured；
• 验收测试工具选用 Selenium。

---

 时牧敏捷社区