近年来 Devops 可以说是比较火的概念，几乎一夜之间全部大公司都在谈 Devops，谈 CI/CD 流水线，谈效能提升；如果哪个公司没有实施 Devops 实践，那么肯定会在心里被鄙视到！

其实 Devops 之所以能火起来，还是因为现在的互联网公司迫于竞争的压力，想要能够先于竞争对手、市场发布自己的产品或需求。而剩下的一部分公司则可能是跟随主流，且不想在前沿的技术实践上太过落后，才实践的 Devops。

不管 Devops 是因为什么原因火起来，终归它还是一个好的实践，可以给团队和公司带来研发流程和效率上的提升。而今天我们就来说说测试环境治理在 Devops 中的几种应用方式。

测试环境治理

测试环境治理是软件测试过程中对被测对象软件环境的管理和调度的总称。简而言之，就是在测试过程中提供简单、方便、高效的软件测试环境的手段。

为什么测试环境治理跟 Devops 能扯上关系呢？因为 Devops 的环节中其中必不可少的就是自动化测试，而自动化测试自然就要涉及到自动化测试环境的搭建和维护，因此就需要有一个针对性的解决方案 -- 测试环境治理。

其实对测试环境的管理和维护，是要更早于 Devops 实践；但是对测试环境的关注和投入，却是因为 Devops 才被放大的。所以才有了多种形式的测试环境治理方案。

基于物理机/VM 的环境编排

在这种情况下并没有真正的使用到虚拟化技术，因为这里的物理机和 VM 都是提前搭建好的固定操作系统，不是那种可以动态创建和还原的虚拟机镜像。因此可以直接认为是在固定的物理环境中搭建和管理测试环境。

对于这种实际情况，最简单的实现方式就是通过 Jenkins 来配置每一个模块，直到把所有的模块都配置完成，这样一套完整的测试环境就可以在 Jenkins 中被管理起来，任意一个模块有更新时，直接触发该模块对应 Jenkins 部署任务就可以了。

优点：可以基于开源的框架直接上手，管理方式简单清晰

缺点：同时管理全套的所有模块则不够灵活，每一个分支都需要单独写一套搭建的流程

除了上面的 jenkins 的方式，还有一种就是开发环境搭建的编排工具。同样的它会负责每一个模块的具体搭建工作，另外它还可以统一管理一套环境中的所有模块。并且提供各模块间的依赖搭建编排功能，甚至可以提供模块状态的监控功能。

优点：统一管理一套环境，提供编排、监控、并发能力

缺点：需要一定的开发工作量

基于 openstack/KVM 的虚拟化编排

选用第一种方式来管理测试环境，通常是因为迫于现状才选择的。如果公司的运维能力相对比较好点，那么你们可能已经使用上了 openstack 等云平台基础架构，并能够提供动态创建虚拟机的服务。

对于这种实际情况，对于测试环境的治理就相对的容易点了，因为你可以把所有模块的基础环境都做成镜像，每次部署模块时可以通过基础镜像来新建或者恢复一个虚拟机，然后再部署好最新的模块即可。

优点：能够提供非常干净的基础搭建环境

缺点：需要一定的运维基础能力支持（公司需要有搭建私有云的技术能力）

基于 docker 的容器化编排

如果公司的运维能力再进一步，你们可能已经使用上容器化技术了。那么恭喜你！在测试环境治理的路上，你又可以更进一步了！通过 docker 的容器化技术，不仅可以实现基础环境的还原，而且是快速的。

对于这种情况，如果配合 K8S 使用，那么还可以同时拥有全套环境统一管理，编排和监控能力。配置完成一套环境后，可以快速搭建一套一模一样的基础环境。

优点：能够快速搭建全套环境，同时提供编排、监控能力

缺点：需要运维的支持、需要 k8s、docker 的实践经验

基于服务虚拟化的环境治理

上面提到的 3 种测试环境治理方案，虽然都能够管理一套环境的搭建，甚至可以快速的复制另一套测试环境。但还是不能覆盖实际工作中的主要场景需求。

比如：开发者 A 因为开发模块 A 需要联调，他可能需要一套环境来自测；同样的开发者 B、C 都会有同样的需求，甚至测试 A，产品 D 都需要一套特定的测试环境来进行测试或者验收。

值得注意的是，上述场景并不是假设的，而是真实存在的；尤其是对于功能模块比较庞大的被测对象。比如：现在比较流程的微服务架构，动辄成百上千的服务模块；想搭建一套完整的服务实属不易，况且还要有空余的机器支持！

所以说上面的 3 种解决方案，最多只能解决单套测试环境的问题，而不能解决多套测试环境并行的问题。对于这种情况就需要使用服务虚拟化技术来解决了。

所谓的服务虚拟化，是相对于容器技术的进程虚拟化而言。即指的是对服务进行隔离和互通的一种技术实现方式。

服务虚拟化的概念是阿里提出的，但是类似的技术方案在其它公司也有实现，且具体技术方案也不一样，但是其基础的思想都是一致的。下面就来介绍下服务虚拟化的测试环境治理方案。

服务虚拟化的前提是，保证已经拥有了一套基础版本的全套模块服务，这里暂且称之为 base 环境。base 环境通常是与线上版本保持一致的线下全套服务环境。

有了 base 环境之后，理想状态下如果其中一个模块被修改了，直接用该模块的测试版本替换掉原来的 base 版本，就可以拥有一套完整的测试环境了。但这里仍然会有几个问题：

1. 替换测试模块的方式会破坏原来的 base 环境
2. 不能同时支持多个模块并发替换和测试

所以服务虚拟化的概念就有了，如何才能实现不同服务间的隔离和共享，来达到环境服务的虚拟化。下面来看一张服务虚拟化的图示。

上图中假设一套环境只有 ABC3 个模块组成，而上面 5 个模块却已经拥有了 3 套环境：一套 base 环境（ABC），2 套虚拟环境（A'BC，ABC'）。依据上面的假设可以推理出，服务虚拟化可以提供任意的一个或多个模块的动态替换，快速的组建起一套基于 base 环境的虚拟环境。

该方案可以说是环境治理的终极方案，但是它的实现依赖于 2 个关键技术点：

• 一是如何实现动态替换 base 环境中的模块，且不影响其它虚拟环境使用该 base 模块
• 二是如何去识别被处理的请求的意图，即请求本身希望被测试模块处理还是被 base 模块处理

关于这 2 点的技术实现，阿里、有赞都已经有了各自的实现方式，感兴趣的同学可以去他们的公众号上查阅相关文章；当然还可以有其它的实现方式，大家也可以自己思考下，欢迎来共同探讨该技术话题！获取更多关于 Python 和自动化测试的文章，请扫描如下二维码！