Gitlab CI 持续集成的完整实践

本着公司团队初创,又在空档期想搞点事情,搭建了私有Gitlab的契机,顺便把持续集成搭建起,实现了对Python服务端代码的单元测试、静态代码分析和接口测试的持续集成。总体架构如下:

执行过程:

  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 镜像:

sudo docker pull gitlab/gitlab-runner

启动容器:

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

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

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

   gitlab/gitlab-runner:latest

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

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-runner尝试去官方的docker hub仓库拉取镜像。通过修改gitlab-runner中的配置,设置只拉取本地镜像:

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

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

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

extra_hosts = ["hostname:ip"]

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

COPY requirement.txt .

RUN pip install -r requirement.txt

编写 .gitlab-ci.yaml

单元测试部分

用nose执行测试

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

pip install nose

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

nosetests

自写测试入口

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

redis与mongo服务化

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

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

docker pull redis:2.8 

docker pull mongo:3.2

在gitlab-ci.yaml中添加services:

services:

 - redis:2.8

 - mongo:3.2

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

静态代码分析

sonarqube搭建

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

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

pip install docker-compose

cd sonarqube-docker

docker-compose up

sonar scanner配置

同时针对Python开源了sonar-scanner镜像的Dockerfile ,该镜像已经安装pylint,方便做Python的静态代码分析。

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

cd sonar-scanner-docker

docker build -t sonar-scanner .

YAML添加执行命令

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

创建一个project

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

获取sonar-scanner执行脚本

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

Sonar分析后评论

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

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

     - sonar-scanner

     -Dsonar.analysis.mode=preview

     -Dsonar.gitlab.commit_sha=$CI_BUILD_REF

     -Dsonar.gitlab.ref_name=$CI_BUILD_REF_NAME

     -Dsonar.gitlab.project_id=$CI_PROJECT_ID

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

持续交付

这部分交由对服务端部署更熟悉的运维操作。

接口测试

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

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

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

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

image: pro1_executor

stages:
  - unittest
  - analyze
  - deploy
  - apitest

variables:
  SONAR_HOST: "http://192.168.0.29:9000"
  SONAR_PROJ: "pro_1"
  SONAR_LOGIN: "b3135dd602b61ce7ff5f4202a3ec2ec0865fa7f5"

services:

  - redis:3
  - mongo:3.2

UnitTest:
  stage: unittest
  script:
  - pip install nose
  - python -m runtest xtest

Sonar_Preview:
  image: sonar-scanner
  stage: analyze
  script:
    - sonar-scanner
    -Dsonar.analysis.mode=preview
    -Dsonar.gitlab.commit_sha=$CI_BUILD_REF
    -Dsonar.gitlab.ref_name=$CI_BUILD_REF_NAME
    -Dsonar.gitlab.project_id=$CI_PROJECT_ID
    -Dsonar.projectKey=$SONAR_PROJ
    -Dsonar.sources=.
    -Dsonar.host.url=$SONAR_HOST
    -Dsonar.login=$SONAR_LOGIN
except:
    - master

Sonar_Analyze:
  image: sonar-scanner
  stage: analyze
  script:
    - sonar-scanner
    -Dsonar.projectKey=$SONAR_PROJ
    -Dsonar.sources=.
    -Dsonar.host.url=$SONAR_HOST
    -Dsonar.login=$SONAR_LOGIN
  only:
    - master 

Deploy_TestServer:
  stage: deploy
  script: echo "deploy"

API_Test:
  stage: apitest
  script:
    - cd /
    - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.xxx.com/yx/apitest.git
    - cd apitest
    - pip install -r requirements.txt
    - python runtest.py

参考:  

[1] https://mp.weixin.qq.com/s/fJPNg8jPkLAd0y8-D7xBYw

原文地址:https://www.cnblogs.com/zengming/p/10318303.html

时间: 2024-10-21 22:23:27

Gitlab CI 持续集成的完整实践的相关文章

Artifactory & GitLab CI持续集成实践

GitLab CI支持创建多个构建,并评估每次代码提交是否通过测试和以及对您产品的影响.在构建过程中,会生成大量二进制文件,如果不能正确的大规模管理这些文件,就会导致二进制文件管理混乱.为了克服这个问题,Artifactory被无缝地集成到GitLab CI构建过程中,以便更好的发布和管理这些二进制文件,并通过JFrog CLI, GitLab CI缓存.发布您的依赖包.制品包和构建信息到Artifactory. 这篇文章描述了如何将 GitLab CI 与 Artifactory 集成在一起,

简单搭建Gitlab CI持续集成环境

简单搭建Gitlab CI持续集成环境 简单介绍Gitlab CI的功能 从GitLab 8.X 开始,GitLab CI就已经集成在GitLab中,我们只要在项目中添加一个.gitlab-ci.yml文件,然后添加一个Runner,开启Runner,即可进行持续集成.而且随着GitLab的升级,GitLab CI变得越来越强大. GitLab Runner 在没使用过Gitlab之前,我也有一个困惑,到底Gitlab Runner是什么东西.它的作用是什么?</br>GitLab Runne

GitLab CI持续集成配置方案

目录 1. 持续集成介绍 1.1 概念 1.2 持续集成的好处 2. GitLab持续集成(CI) 2.1 简介 2.2 GitLab简单原理图 2.3 GitLab持续集成所需环境 2.4 需要了解知识 3. 搭建GitLab持续集成环境(NET版) 3.1 环境搭建 3.1.1 基础环境搭建 3.1.2 Git安装 3.1.3 NuGet安装 3.2 相关配置 3.2.1 Git环境变量配置 3.2.2 PowerShell调用测试 3.2.3 GitLab-Runner下载 3.3 Git

Gitlab CI持续集成 - GitLab Runner 安装与注册

GitLab Runner安装 需要添加gitlab官方库: # For Debian/Ubuntu/Mint curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash # For RHEL/CentOS/Fedora curl -L https://packages.gitlab.com/install/repositories/runner/g

如何用 Gitlab 一键实现 CI 持续集成?

背景 在目前快节奏生活已经成为社会风潮的大背景下,越来越多的互联网公司为了其应用产品能更快的掌控风向脉搏,抢占市场红利,需要更快速的应用产品开发上线,在市场的反馈下,不断的迭代新功能.在此需求下,持续集成,持续部署,持续交付被越来愈多公司所推崇,DevOPS文化的兴起,一方面是实践打破运维与研发的堡垒之墙,另一方面也是敏捷开发过程中的必要产物. 提高软件开发效能,快速迭代.快速试错,以及根据自己开发团队特点,使用怎样的技术手段,才能是软件开发效能最高,更为快速敏捷,以及怎样才能满足产品能在最短周

记一次完整的CI持续集成配置过程(.net core+Jenkins+Gitea)

Jenkins大家一定很熟悉.以前我也配过,这次的需求是当后台开发工程师向git server提交代码以后,jenkins服务器自动去抓取,然后编译,发布,我起初觉得这是个很简单的事情,应该半个小时搞定吧. 事实上,不但半个小时没搞定,我最后 折腾了三天,经历了38次失败,最终在第39次才完全配置成功. 把经历的过程写下来,供后来者参考,避免踩坑. 一.本次配置环境: 1.需求: 后端工程师提交代码->Push到Git Server(使用Gitea自已搭建)->经路由器映射触发内网Jenkin

[首发]国内某大型银行的持续集成与交付实践

一.背景 随着架构的不断演进以及微服务技术在我行的深入应用,应用部署发布的复杂性大大增加,简单的代码配置管理模式.人工的版本记录及手工部署等发布操作和管理的模式,效率低.操作风险较大,因此急需从整体上提升我行软件持续交付的能力,降低应用部署发布的操作风险.通过引入构建自动化及可视化的软件交付流水线,整合从开发.构建.测试.部署.发布.运维等多个环节,加强各职能团队协助和沟通,全面实现项目构建持续自动化管理. 二.实施方法 1. 总体架构 DevOps是一组能够帮助软件开发团队极大的提高其软件交付

美团点评:打造微服务自动化测试与持续集成工具链实践

本文内容节选自第六届全球软件案例研究峰会,时任美团点评酒旅质量团队工具链负责人王鹏老师分享的<微服务架构下的自动化测试和持续集成工具链实践>实录,重点分享:微服务架构下解决自动化测试.开发联调.测试环境.持续集成方面遇到的问题及解决方案.(PPT+文稿). 王鹏老师时任美团点评酒旅质量团队工具链负责人,在软件开发,自动化测试,研发流程改进,持续集成/交付基础设施,敏捷开发等领域有近10年的开发实施和推广经验. 编者按:2017年11月9-12日,第六届全球软件案例研究峰会在北京国家会议中心盛大

docker搭建gitlab+Jenkins持续集成环境

安装docker 此处省略一.使用docker安装gitlab docker pull gitlab/gitlab-ce:latest下载完成之后使用docker生成容器docker run -dit \-p 8443:443 \-p 8080:80 \-p 2222:22 \-p 9090:9090 \--name gitlab \--restart always \-v /home/gitlab/config:/etc/gitlab \-v /home/gitlab/logs:/var/lo