基于Docker的可持续交付问题
在测试的立场上,希望开发编写的代码都是经过开发的单元测试的,但是事实上,这中间总是存在理想和现实的差距,既然如此,我们何不来开发部署环境后,对服务进行自动化测试验证了。整体的设计思路就是开发编写的代码,使用Dockerfile构建成镜像文件,然后使用docker-compose自动化启动镜像文件,下一步其实就很简单了,我们测试这边进行智能化的自动验证,其实在前面的文章体系中,介绍中智能化测试完成后,在测试结束的时候出具体的测试报告以及如果存在问题,触发整体报警的机制。本文章系列中主要结合CI持续集成的工具,把这个过程完全的自动化,以及智能化的过程。当然,使用的技术栈主要是Spring Boot。
创建Spring Boot的项目后,这地方简单的写一个测试的接口,controller层源代码具体如下:package com.example.app;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class AppController
{
@RequestMapping("/index")
public String hello()
{
return "Hello SpringBoot!";
}
@RequestMapping("/testDev")
public String testDev()
{
return "测试开发工程师";
}
}
这部分的代码其实相对而言是非常简单的,这里就不做详细的解释了。编写代码完成后,下来编写Dockerfile的文件来构建镜像,Dockerfile在项目中存放的位置主要是在src/main下的docker文件夹,创建docker文件夹后,在里面创建Dockerfile的文件,然后在里面包编写需要构建镜像的内容信息,具体目录结构如下所示:
Dockerfile文件夹的内容具体为:FROM java:8
MAINTAINER 乐却思蜀
VOLUME /tmp
RUN mkdir /app
COPY app-0.0.1-SNAPSHOT.jar /app/app.jar
WORKDIR /app
EXPOSE 8081
CMD ["java","-Djava.security.egd=file:/dev/./urandom","-jar","app.jar"]
下来在docker的文件夹创建docker-compose.yml文件,在该文件主要定义镜像的资源,网络以及启动停止的过程,该文件的内容信息具体如下:
`version: ‘3.2’
services:
app:
image: app:0.0.1-SNAPSHOT
hostname: localhost
ports:
- "8081:8081"
networks:
- mynetwork
networks:
mynetwork:
external: true在如上的文件中可以看到自定义了网络是mynetwork,在docker中可以创建网络,以及查看目前已有的网络信息,具体如下:
docker network ls
NETWORK ID NAME DRIVER SCOPE
5e0d06b35341 bridge bridge local
34f731bed1dc host host local
4b5926f1e44d mynetwork bridge local下来编写测试的代码,测试的代码这里使用Python语言结合Pytest测试框架来编写,具体测试模块test_sprintboot.py的源码如下:
import requests
import pytest
def test_springboot_index():
r=requests.get(“http://localhost:8081/index“)
assert r.status_code==200
def test_springboot_testDev():
r=requests.get(“http://localhost:8081/testDev“)
assert r.status_code == 200
`
这个测试代码相对而言是比较简单的,这里主要需要验证的是服务自动化部署后智能化的验证。
在如上的准备工作做好,下来在Jenkins中创建Pipeline的项目,Pipeline script的脚本具体如下: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中构建和执行过程,构建后可视化的界面信息如下所示:
输出的详细信息在这里只显示部分,具体如下:======================== 2 passed, 3 warnings in 0.72s =========================
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
对于质量交付团队而言,需要思考的点是,我们怎么样结合现有的技术来达成我们的目标和质量验证的手段。其实一种验证的研发体系流程是开发无论如何需要对自己编写的代码进行单元测试,这样其实一个体系它是通过,整体体系我们完全可以持续流水线的方式来进行验证,从而提高交付的效率以及提交给测试团队是高质量的代码。其实如上的思路很简单,就是从Docker构建镜像,到启动容器,以及我们进行冒烟测试验证,当然后续还有很多的流程,比如测试团队其他的验证手段,比如代码质量审计,API等验证。
推荐阅读
-
基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境的详细教程
-
C/C++ 基于 Jenkins、Conan 和 Artifactory 的持续交付
-
基于Docker部署Tomcat集群、 Nginx负载均衡的问题小结
-
基于容器服务的持续集成与云端交付(一)- 交付之禅 单元测试框架编程
-
Docker实践过程中遇到的一些问题总结(持续更新中)
-
基于Docker的可持续交付问题
-
基于Docker+K8S+GitLab/SVN+Jenkins+Harbor搭建持续集成交付环境的详细教程
-
基于Docker的可持续交付问题
-
Jenkins + Docker + SVN + Maven 持续集成环境搭建过程中遇到的问题
-
基于Docker部署Tomcat集群、 Nginx负载均衡的问题小结