docker容器 eureka 集成_CATS项目实践持续集成与docker容器化

CATS项目

CATS自动化测试平台：采用已经逐渐成为业界标准方式的前后端分离架构，前端使用vue-cli快速开发，后端使用Spring Boot进行分布式构建部署，两个全家桶强强联合。以简单优雅的方式整合shiro、swagger、mybatis、druid等优秀的开源互联网架构，实现restful风格api，自定义状态码，json-web-token，druid数据库连接池，swagger文档生成，redis存储refreshtoken和动态秘钥，多数据源管理等。通过采用vue-element-UI做前端模板，摆脱写jQuery的痛苦。采用前后端分离的分布式架构不仅会为自动化测试平台成为大型分布式架构、微服务架构、多端化服务(多种测试类型，例如：UI界面测试、接口测试、RTSP、OPSP前台自动化测试等等)打下坚实的基础。而且为下一代结算系统进行新技术研究探索提供技术储备。 CATS项目基础架构图

- 引言 

续集成作为先进的项目实践之一，近年来逐渐受到国内软件公司的重视；但对于许多开发者来说，可能从来都没有听说过持续集成这个词，抑或只是了解一个概念但并没有实践过。持续集成是指频繁地将代码集成到主干，以便快速发现错误、防止分支大幅度偏离主干。持续集成目的是在产品快速迭代的同时保持代码质量，其核心措施主要有两点： 

1. 代码集成到主干之前，必须通过自动化测试，简单来说，集成测试就是把一切的单元测试跑一遍，以及其它一些能自动完成的测试。只要经过了集成测试的代码才敢上传到代码效劳器上，确保上传的代码没有问题
2. 通过Code Review、代码质量分析工具对代码质量进行把关，以便确定是否能够集成。Martin Flower说过，“持续集成并不能消除Bug，而是让他们非常容易发现和改正。”

- 持续集成实施背景

前面介绍过，CATS项目采用前后端分离的分布式架构。其核心思想是前端html页面通过ajax调用后端的restuful api接口并使用json数据进行交互。以前测试工具开发模式是，开发先设计然后做html页面，然后将html页面套成jsp页面。在前后端强依赖的模式下，后端必须要等前端的html做好才能套jsp。如果html发生变更，jsp内有较多标签和表达式，开发在修改页面时会捉襟见肘，遇到很多痛点。集成出现问题前端返工后端返工二次集成，开发效率低。其次，动态资源和静态资源全部耦合在一起，服务器压力大，因为服务器会收到各种http请求，例如css的http请求，js的，图片的等等。一旦服务器出现状况，前后台一起玩完。        随着系统架构改变，开发模式也相应的产生变化。现在的开发模式是前端设计开发好页面，前后端约定接口，以及接口所需要的数据与参数。此模式下前后端相互之间并没有强依赖，可前后端并行开发，如果需求变更，只要接口&参数不变，就不用两边都修改代码。随着前端工程大量的组件代码抽出来实现组件化，组件之间可以得到高效复用，开发效率得以提升。在后续集成过程发现的bug，也能方便快捷的定位问题的所属，例如页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题，全部由前端工程师来负责。接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。双方互不干扰，前端与后端是相亲相爱的一家人。基于前后端独立开发的模式中可能会由于前后端设计思路不同，在开发实现的过程中产生偏差。等大体开发完成在最后集成的时候才发现问题，开发需要在集成阶段花费大量的时间来寻找 bug 的根源。因此需要在开发过程就进行频繁的构建，集成测试。在实际工作中，接口开发完成后，通常会在本地启动，通过传统的接口测试工具Postman进行人工测试。在开发过程中经常碰到一下问题：

• 开发机网段不同，后端本地启动服务，前端访问不到。
• 修改代码，每次集成都需要进行手动打包，部署到测试环境集成
• 测试环境出问题

随着项目的功能不断的完善和服务节点增加，每次开发需求进行手工打包，部署过程日渐频繁与复杂。每天完成这些大量重复，繁琐的操作，不仅占用开发不少的时间降低开发效率，而且手工操作不小心将导致测试环境出问题。现阶段需要一种自动化将代码自动编译成可运行的版本，部署到测试环境与前端进行集成测试的工具。

- 实践

下面介绍下我们采用的持续集成流程，如下图所示首先开发人员完成本地的代码开发，自测无问题后提交代码并且push到gitlap源码管理仓库(rtc等仓库)。gitLap仓库代码更新出发hook，触发持续集成工具jenkins拉取最新的主干/分支的代码，进行编译打包。这里可能涉及一些依赖程序，我们是通过Gradle项目拉取依赖进行构建、编译打包，进行单元测试通过后完成静态代码扫描。随后就可以将打包后的项目放入提前制作好的tomcat服务器镜像制作新的镜像。将完成的镜像push到harbor镜像仓库进行镜像版本管理，最后从harbor仓库中拉取最新的版本，实例化最新的docker容器即可进行与前端的集成测试。

jenkins持续集成配置

1. Gitlap中Webhook配置，在配置webhook的时候，选择自己想要接收的事件。可以通过API或者UR随时订阅事件。默认情况下，webhook只订阅push事件。

   

   Pipeline编写相应的触发构建命令

   

2. 配置Gitlap源码管理

3. 进行拉取代码打包编译，单元测试

4. 进行代码静态扫描。在代码静态扫描环节，通过pipeline灵活对接jenkins与sonarqube两个平台。快速对代码行的单元测试覆盖率、重复率、代码坏味道等指标进行监控，对未达到设定代码质量阀的构建，快速失败反馈。主要包含如下几个优势。

   (1)坏味道代码规范。参考互联网头部厂商总结出48条针对java语言行之有效的编码规，涵盖多层次问题。
   (2)多种灵活的检测方式(RTC插件等)督促开发进行高效规范的开发，进行高效的协同工作。
   (3)协助项目经理快速对项目进行质量管控,根据坏味道的数量与种类，为决策提供商业化的参考数据。
   (4)据数据统计，30%至70%的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复。

5. 进行docker镜像制作，通过编写好的dockerfile文件快速进行镜像制作，push到harbor镜像仓库中保存。

   

6. 从镜像仓库中拉取镜像实例运行容器，服务即可提供给前台进行集成。最后效果如图，后台采用swagger根据接口代码生成接口文档。

   

- 总结

通过结合jenkins工具与docker进行实现持续集成实践，将后端服务的构建，打包，测试，部署测试环境交由流水线自动完成。任一项目成员均可经过简单介绍，即可进行项目发布，验证新完成的功能是否合乎需求，代码编写质量是否符合规范。将开发从复杂重复的打包，部署中解脱出来，有效的降低项目在开发阶段的时间成本与人力成本，并且提高项目整体质量，开发通过对新代码功能快速验证，提高对项目的信心。

从编码提交到部署动态图