在测试的立场上，希望开发编写的代码都是经过开发的单元测试的，但是事实上，这中间总是存在理想和现实的差距，既然如此，我们何不来开发部署环境后，对服务进行自动化测试验证了。整体的设计思路就是开发编写的代码，使用Dockerfile构建成镜像文件，然后使用docker-compose自动化启动镜像文件，下一步其实就很简单了，我们测试这边进行智能化的自动验证，其实在前面的文章体系中，介绍中智能化测试完成后，在测试结束的时候出具体的测试报告以及如果存在问题，触发整体报警的机制。本文章系列中主要结合CI持续集成的工具，把这个过程完全的自动化，以及智能化的过程。当然，使用的技术栈主要是Spring Boot。
创建Spring Boot的项目后，这地方简单的写一个测试的接口，controller层源代码具体如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
package com.example.app;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.RestController;@RestControllerpublic class AppController{ @RequestMapping("/index") public String hello() { return "Hello SpringBoot!"; } @RequestMapping("/testDev") public String testDev() { return "测试开发工程师"; }} |
这部分的代码其实相对而言是非常简单的，这里就不做详细的解释了。编写代码完成后，下来编写Dockerfile的文件来构建镜像，Dockerfile在项目中存放的位置主要是在src/main下的docker文件夹，创建docker文件夹后，在里面创建Dockerfile的文件，然后在里面包编写需要构建镜像的内容信息，具体目录结构如下所示:
Dockerfile文件夹的内容具体为：
|
1
2
3
4
5
6
7
8
|
FROM java:8MAINTAINER 乐却思蜀VOLUME /tmpRUN mkdir /appCOPY app-0.0.1-SNAPSHOT.jar /app/app.jarWORKDIR /appEXPOSE 8081CMD ["java","-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"] |
下来在docker的文件夹创建docker-compose.yml文件，在该文件主要定义镜像的资源，网络以及启动停止的过程，该文件的内容信息具体如下:
|
1
2
3
4
5
6
7
8
9
10
11
12
|
version: '3.2'services: app: image: app:0.0.1-SNAPSHOT hostname: localhost ports: - "8081:8081" networks: - mynetworknetworks: mynetwork: external: true |
在如上的文件中可以看到自定义了网络是mynetwork，在docker中可以创建网络，以及查看目前已有的网络信息，具体如下：
|
1
2
3
4
5
|
docker network lsNETWORK ID NAME DRIVER SCOPE5e0d06b35341 bridge bridge local34f731bed1dc host host local4b5926f1e44d mynetwork bridge local |
下来编写测试的代码，测试的代码这里使用Python语言结合Pytest测试框架来编写，具体测试模块test_sprintboot.py的源码如下：
|
1
2
3
4
5
6
7
8
|
import requestsimport pytest def test_springboot_index(): r=requests.get("http://localhost:8081/index") assert r.status_code==200def test_springboot_testDev(): r=requests.get("http://localhost:8081/testDev") assert r.status_code == 200 |
这个测试代码相对而言是比较简单的，这里主要需要验证的是服务自动化部署后智能化的验证。
在如上的准备工作做好，下来在Jenkins中创建Pipeline的项目，Pipeline script的脚本具体如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
pipeline{ agent any stages{ stage('build the image'){ steps{ sh '''cd /Applications/code/workSpace/data/app mvn clean package -Dmaven.test.skip=true docker:build''' } } stage('run the container'){ steps{ sh '''cd /Applications/code/workSpace/data/app/src/main/docker docker-compose up -d ''' } } stage('smoke test'){ steps{ sh '''cd /Applications/code/workSpace/data/app/src/main/docker sleep 10s python3 -m pytest -v test_springboot.py''' } } }} |
下来开始在CI中构建和执行过程，构建后可视化的界面信息如下所示：
输出的详细信息在这里只显示部分，具体如下：
|
1
2
3
4
5
6
7
|
======================== 2 passed, 3 warnings in 0.72s =========================[Pipeline] }[Pipeline] // stage[Pipeline] }[Pipeline] // node[Pipeline] End of PipelineFinished: SUCCESS |
对于质量交付团队而言，需要思考的点是，我们怎么样结合现有的技术来达成我们的目标和质量验证的手段。其实一种验证的研发体系流程是开发无论如何需要对自己编写的代码进行单元测试，这样其实一个体系它是通过，整体体系我们完全可以持续流水线的方式来进行验证，从而提高交付的效率以及提交给测试团队是高质量的代码。其实如上的思路很简单，就是从Docker构建镜像，到启动容器，以及我们进行冒烟测试验证，当然后续还有很多的流程，比如测试团队其他的验证手段，比如代码质量审计，API等验证。感谢您的阅读和关注，后续会持续进行更新。
到此这篇关于基于Docker的可持续交付的文章就介绍到这了,更多相关Docker可持续交付内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://www.cnblogs.com/1024testing/archive/2022/01/05/15768711.html
