Gitlab CI 持续集成的完整实践

Gitlab CI 持续集成的完整实践_第1张图片

来源:https://dwz.cn/mWyVHoSm

借着公司代码库迁移到私有Gitlab的契机,我接下持续集成的工作,实现了对Python服务端代码的单元测试、静态代码分析和接口测试的持续集成。总体架构如下:

Gitlab CI 持续集成的完整实践_第2张图片

执行过程:

  1. 开发提交代码后,自动触发gitlab-runner拉取executor镜像执行单元测试,单元测试代码中包含上传测试结果到x-utest测试平台;

  2. 单元测试通过后,gitlab-runner拉取sonar-scanner镜像执行静态代码分析,分析结果评论在commit中或保存于sonarqube;

  3. 静态代码分析结束,执行分发操作,将代码分发至灰度测试服务器,并运行;

  4. 执行接口测试,执行完成后上传测试结果到x-utest测试平台。

四个任务相互依赖,只在前一个任务状态为成功情况下才会执行。

本文主要描述一些技术实现,会适当贴出代码,可能能为相关从业者提供灵感与解决方案,不保证每个细节都深入讲解。

Gitlab CI 基本配置

针对某个需要做CI/CD的项目,需要将代码库的该设置打开,并为其配置 gitlab-runner。

gitlab runner

gitlab-runner不仅可以运行在物理机,还可以运行在容器中。考虑到gitlab-runner消耗的资源少,使用容器更合适。

拉取gitlab-runner Docker 镜像:

 
   

  1. sudo docker pull gitlab/gitlab-runner


启动容器:

 
   

  1. sudo docker run -d --name gitlab-runner --restart always \

  2.    -v /srv/gitlab-runner/config:/etc/gitlab-runner \

  3.    -v /var/run/docker.sock:/var/run/docker.sock \

  4.    gitlab/gitlab-runner:latest


在容器中执行register操作,将gitlab上的项目注册到gitlab-runner中:

 
   

  1. sudo docker exec -it gitlab-runner gitlab-ci-multi-runner register


输入上述命令后会有一系列的配置需要输入,当然也可以设置完后进行更改 按照提示输入即可,前两项可以在指定项目设置中CI/CD选项里的Runners settings选项中的Specific Runners里看到,tags是gitlab-ci.yml文件中所要用到的,executor选择docker 配置成功后,我们可以在设置中CI/CD选项里的Runners settings选项中的Specific Runners里看到runner信息

本地executor镜像

为了部署与测试,需要一个镜像用于执行。当选用本地镜像时,会发现如下报错

Gitlab CI 持续集成的完整实践_第3张图片

拉取镜像失败

报错的原因在于,gitlab-runner尝试去官方的docker hub仓库拉取镜像。通过修改gitlab-runner中的配置,设置只拉取本地镜像:

修改 /etc/gitlab-runner/config.toml ,在 [runners.docker] 下,添加:

 
   

  1. pull_policy = never  # 该配置默认always,即只在线上拉取镜像


如果有需要添加一些hosts映射,仍然在 [runners.docker] 下,添加:

 
   

  1. extra_hosts = ["hostname:ip"]


另外为了加快单元测试执行速度,将服务端代码的依赖提前安装至executor镜像中:

 
   

  1. COPY requirement.txt .



  2. RUN pip install -r requirement.txt


编写 .gitlab-ci.yaml

单元测试部分

用nose执行测试

对于Python,nosetest工具可以嗅探与执行你写的所有测试用例,并输出结果。在执行测试前,使用nose需要使用pip安装

 
   

  1. pip install nose


安装完成后,使用 nosetests 执行。

 
   

  1. nosetests


自写测试入口

另一个执行测试的选择,是自写测试入口,不依赖nose。好处是能够将测试结果上传至x-utest。 对测试结果做判断,如果全部用例通过(即wasSuccessful为True),则sys.exit(0),否则sys.exit(1)

redis与mongo服务化

对于redis与mongo这种外部服务,有两种解决方式,一是mock对数据库的读写,二是使用服务化的redis与mongo,保证外部环境的一致性。(更推荐第一种方式,此处介绍第二种。)

由于设置了不从docker hub拉取镜像,因此需要先拉取redis与mongo服务镜像到本地

 
   

  1. docker pull redis:2.8



  2. docker pull mongo:3.2


在gitlab-ci.yaml中添加services:

 
   

  1. services:

  2.  - redis:2.8

  3.  - mongo:3.2


修改代码的local_config配置文件中的mongo与redis连接URL,指向“mongo”与“redis”

静态代码分析

sonarqube搭建

制做了一个docker-compose项目可以一键部署SonarQube平台 <==欢迎fork/start,使用postgres作为后端数据库,并将数据持久化在宿主机本地。

 
   

  1. git clone https://github.com/ityoung/sonarqube-docker.git



  2. pip install docker-compose



  3. cd sonarqube-docker



  4. docker-compose up


sonar scanner配置

同时我也针对Python开源了sonar-scanner镜像的Dockerfile <==欢迎fork/start,该镜像已经安装pylint,方便做Python的静态代码分析。

 
   

  1. git clone https://github.com/ityoung/sonar-scanner-docker.git



  2. cd sonar-scanner-docker



  3. docker build -t sonar-scanner .


YAML添加执行命令

启动SonarQube后,进入IP:9000到SonarQube管理页面,登录admin/admin,新建一个项目,按步骤执行完成

Gitlab CI 持续集成的完整实践_第4张图片

创建一个project

创建完成后,获取到执行代码,复制这段代码,添加到yaml中,能够实现分析结果上传到SonarQube。

Gitlab CI 持续集成的完整实践_第5张图片

获取sonar-scanner执行脚本

注意:如果yaml中用到了两个镜像,尽量不要有before_script,否则可能两个镜像,触发错误。

Sonar分析后评论

对于develop分支,可以不保存分析结果,而改为将分析结果评论在当次commit下。

在yaml脚本中添加如下参数:

 
   

  1.    - sonar-scanner

  2.      -Dsonar.analysis.mode=preview

  3.      -Dsonar.gitlab.commit_sha=$CI_BUILD_REF

  4.      -Dsonar.gitlab.ref_name=$CI_BUILD_REF_NAME

  5.      -Dsonar.gitlab.project_id=$CI_PROJECT_ID


注意:无新issue时默认不会评论,需要在SonarQube修改gitlab配置才会每次都评论。

持续交付

这部分交由对服务端部署更熟悉的运维操作,因此不做赘述。

接口测试

接口测试代码在另一个仓库,这就涉及到从另一个仓库clone测试代码时的权限问题。

给仓库URL添加token能够实现跨仓库clone代码:

 
   

  1. git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.xxx.com/yx/apitest.git


附一:完整的.gitlab-ci.yml

 
   

  1. image: pro1_executor




  2. stages:

  3.  - unittest

  4.  - analyze

  5.  - deploy

  6.  - apitest




  7. variables:

  8.  SONAR_HOST: "http://192.168.0.29:9000"

  9.  SONAR_PROJ: "pro_1"

  10.  SONAR_LOGIN: "b3135dd602b61ce7ff5f4202a3ec2ec0865fa7f5"




  11. services:

  12.  - redis:3

  13.  - mongo:3.2




  14. UnitTest:

  15.  stage: unittest

  16.  script:

  17.  - pip install nose

  18.  - python -m runtest xtest




  19. Sonar_Preview:

  20.  image: sonar-scanner

  21.  stage: analyze

  22.  script:

  23.    - sonar-scanner

  24.      -Dsonar.analysis.mode=preview

  25.      -Dsonar.gitlab.commit_sha=$CI_BUILD_REF

  26.      -Dsonar.gitlab.ref_name=$CI_BUILD_REF_NAME

  27.      -Dsonar.gitlab.project_id=$CI_PROJECT_ID

  28.      -Dsonar.projectKey=$SONAR_PROJ

  29.      -Dsonar.sources=.

  30.      -Dsonar.host.url=$SONAR_HOST

  31.      -Dsonar.login=$SONAR_LOGIN

  32.  except:

  33.    - master




  34. Sonar_Analyze:

  35.  image: sonar-scanner

  36.  stage: analyze

  37.  script:

  38.    - sonar-scanner

  39.      -Dsonar.projectKey=$SONAR_PROJ

  40.      -Dsonar.sources=.

  41.      -Dsonar.host.url=$SONAR_HOST

  42.      -Dsonar.login=$SONAR_LOGIN

  43.  only:

  44.    - master



  45. Deploy_TestServer:

  46.  stage: deploy

  47.  script: echo "deploy"



  48. API_Test:

  49.  stage: apitest

  50.  script:

  51.    - cd /

  52.    - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.xxx.com/yx/apitest.git

  53.    - cd apitest

  54.    - pip install -r requirements.txt

  55.    - python runtest.py


参考

[1] how to access multiple repositories in CI build?, Stack Overflow


号外:最近整理了一下以前编写的一系列Spring Boot内容,整了个《Spring Boot基础教程》的PDF,关注我,回复:001,快来领取吧~!002 资源也即将整理出炉,先关注我吧!随后奉上更多精选学习资料!!!



·END·


 近期热文:

  • SpringCloudAlibaba基础教程:使用Nacos实现服务注册与发现

  • 老板扣了我1000,因为我没记住阿里巴巴开发手册的这条规则。

  • “三次握手,四次挥手”你真的懂吗?

  • “拼多多”被薅的问题出在哪儿?损失将如何买单?

  • 在前后端分离的路上承受了多少痛?看看这篇是否能帮到你?

  • 你真的会高效的在GitHub上搜索开源项目吗?

  • Spring Boot:自定义starter

  • 中台是个什么鬼?

  • 从业务到平台的思维转变

  • 是什么使你留在你的公司

640?wx_fmt=png

看完,赶紧点个“好看”鸭

点鸭点鸭

↓↓↓↓

你可能感兴趣的:(Gitlab CI 持续集成的完整实践)