请注意,CI流程中运行模拟测试的真正目的是执行那些需要服务及其依赖项运行起来的测试。这些还不是需要生产或类生产环境的集成测试。这些测试背后的想法是将服务与其直接依赖项一起运行,进行测试,在完成后全部移除并释放资源用于其他任务。由于这些还不是集成测试,因此可以模拟一些依赖项。
由于这些测试的性质,需要将任务分成以下三个操作。
(1)运行服务及其所有依赖项。
(2)运行测试。
(3)销毁服务及其所有依赖项。
依赖关系被定义为docker-compose-test-local.yml文件中的staging-dep服务(https://github.com/vfarcic/go-demo/blob/master/docker-compos e-test-local.yml)。定义如下:
这里的镜像是go-demo,它公开了8080端口(在主机和容器内)。它依赖于一个mongo镜像的db服务。定义为depends_on的服务将在定义依赖关系的服务之前运行。换句话说,如果运行staging-dep target,则Compose将首先运行db服务。
让我们按照下面的代码运行依赖关系:
一旦命令完成,就会有两个运行中的容器(go-demo和db)。可以通过列出所有进程来确认:
输出如下:(www.xing528.com)
既然依赖的服务和数据库已经在运行,那么可以执行测试了。这些测试被定义为staging服务。定义如下:
由于预备测试的定义与我们运行的单元测试非常相似,所以使用staging服务扩展unit服务。通过扩展服务,我们继承它的完整定义。接下来定义一个环境变量HOST_IP。测试代码使用该变量来确定被测试服务的位置。在这种情况下,由于go-demo服务与测试运行在同一台服务器上,因此IP是服务器的localhost。默认情况下,由于容器内部的localhost与主机的不同,所以必须将network_mode定义为host。最后定义要执行的命令,它将下载测试依赖项go get-d-v-t并执行测试go test--tags integration-v。
让我们运行如下命令:
所有的测试都通过,离我们确信该服务可以安全部署到生产环境的目标更进一步。
没有任何必要留着服务和数据库继续运行,所以让我们删除它们并释放资源给其他任务:
down命令停止并删除Compose文件中定义的所有服务,可以通过运行以下ps命令来验证:
输出如下:
离完成CI流程还差一件事情。此时我们拥有仅在go-demo服务器内可用的go-demo镜像。我们应该将其存储在镜像库中,以便可以从其他服务器访问它。
免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。