本文将重点讨论在Jenkins管理的持续集成以及测试的环境中,我们如何通过引入Docker来优化资源的配置,提高整个环境的性能以及稳定性。
Jenkins是被广泛应用的持续集成、自动化测试、持续部署的框架,甚至有些项目组顺便将其用来做流程管理的工具。根据任务的多寡,Jenkins通常有两种典型的部署方式。
Docker是一款针对程序开发人员和系统管理员来开发、部署、运行应用的一款虚拟化平台。Docker 可以让你像使用集装箱一样快速的组合成应用,并且可以像运输标准集装箱一样,尽可能的屏蔽代码层面的差异。Docker 会尽可能的缩短从代码测试到产品部署的时间。简单来说Docker提供了一种技术,可以让开发人员方便地将应用代码已经运行时的环境一并打包到一个镜像中,然后将这个镜像上传至镜像仓库。在测试或者产品环境只需要下载这个镜像然后将其启动就完成了部署(就好比打开一个集装箱那么简单)。关于Docker更详细的内容请参考 官网文档 。
随着敏捷开发的普及,自动化测试成为每个项目的必须。一个经过多年开发的项目,其累积的自动化测试数量是惊人的。为了保证每次的部署都是正确的,就需要每次回归所有的自动化测试用例。根据项目的不同,有些需要每周跑一轮回归测试,而有些项目则需要每天一轮。所以我们会把所有的测试用例进行分组,同时在多台测试机上运行,以减少一轮测试所需要的时间。而这就要求我们有足够多的硬件资源来满足这需求。下图展示了一个典型的通过Jenkins来管理自动化测试的拓补结构。一台Master主机管理多台测试机,Master将测试任务分配给测试机。
当前Jenkins(Master-Slave)结构
这种结构存在一些缺陷:
很自然的一个想法就是将测试机全部替换成Docker容器(Container),而管理这些容器的工作交给更专业的工具,如Google的Kubernetes或者Docker官方提供的Swarm。所有构建的环境都打包进Docker的镜像文件中,自动化测试是一个镜像,编译单元测试是一个镜像等等。改进后的拓扑结构如下图所示:
引入Docker以后的结构
在这个方案中唯一的技术问题是自动化测试需要桌面系统,而通常Docker容器中运行的都是无图形界面的应用。解决的方法也非常直接,我们在容器中提供桌面系统(VNC服务)。根据不同的Linux发行版本,我们可以选择TightVNC或者TightVNC。不论选择哪种VNC服务,他们都提供一个虚拟桌面,可以通过VNC的客户端远程连接到该桌面进行操作。
对应前文提到的6个不足,在这种结构下悉数得到了解决。
一个项目开发了5年,就累积了上万回归测试,需要几十台测试机不间断的运行8、9个小时才能完成;设想下,这个项目还要继续运行5年甚至10年呢?我们的测试机的数量将会是多少,我们的测试反馈周期还是8、9个小时么?根据我们的观察,经过多年的维护,很多功能模块已经是非常完善,基本很少有代码的修改。那么这些功能对应的测试用例是否有必要每次都跑呢?答案我想是否定的,但问题是怎么来判断当前代码的修改是否会影响到这些功能模块呢?按照现在的设计,我想没有人敢百分百的肯定。我们是否有必要对现有代码做些调整,依照微服务的思想,把我们的分发包拆分下,每次只需要发布有更新的模块。如此一来我们递归的自动化测试用例也只需要包含有改动的那些模块。那时候,很可能我们可以在每次代码提交就运行一次回归测试。
原文链接: Jenkins+Docker搭建持续集成测试环境