gitlab CI/CD学习笔记

本文转载自https://www.jianshu.com/p/5b76f4f34bb0

CI/CD 介绍

  • 持续集成(Continuous Integration)
  • 持续交付(Continuous Delivery)
  • 持续部署(Continuous Deployment)

持续集成

持续集成指的是频繁地将代码集成到主干,强调开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。

持续交付

持续交付指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

持续部署

持续部署是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。

持续交付和持续部署的区别

说白了,持续交付就是自动地从仓库将最新的程序部署到测试环境里,持续部署就是自动地将稳定版本部署到生产环境里。
深度截图_选择区域_20200426213023

CI/CD流程

一般每个团队不一样,这里提供一种思路
深度截图_选择区域_20200426214231

  1. 提交
  2. 测试(第一轮)
    • 单元测试:针对方法或模块的测试(至少)
    • 集成测试:针对整体产品的某个功能的测试,又称功能测试
    • 端对端测试:从用户界面直达数据库的全链路测试
  3. 构建
    通过测试后,代码合并到主干,可以进行构建,所谓构建,指的是将源码转换为可以运行的实际代码,比如安装依赖,配置各种资源等等。
  4. 测试(第二轮)
    • 全面测试,自动化为主,少数无法自动化的测试用例,就要人工跑。
    • 新版本的每一个更新点都必须测试到。
  5. 部署
  6. 回滚

常见CI/CD工具

  1. jenkins
    免费 + 插件,Jenkins闪耀的地方是其丰富的插件生态系统。它提供了超过1000个插件的扩展版本,可以集成几乎所有市场上可用的工具和服务。作为一个开源工具,您还可以选择自定义适合本土解决方案。
  2. Bamboo
    Bamboo 是Atlassian产品套件的一部分,与其他工具类似,它提供构建,测试和部署代码并支持多种语言。它与其他与CI循环相关的Atlassian产品(如JIRA和Bitbucket)有很强的集成。
  3. Circle CI, Travis CI, TeamCity, CodeShip等等
  4. gitlab CI/CD

gitlab CI/CD

Gitlab持续集成是Gitlab提供的一整套持续集成、持续交付解决方案。

配置步骤

使用gitlab持续集成需要两步(不分先后)

  1. 在repository项目根目录创建.gitlab-ci.yml文件
    • 这个文件是你定义ci任务的地方,每一次push代码到repository,gitlab都会扫描这个文件,按照上面的配置执行相应的任务。
    • 详见.gitlab-ci.yml配置
  2. 安装并配置gitlab runner
    • gitlab runner是运行ci任务的角色,可以是一个虚拟机,一个物理机,或者一个docker容器,甚至容器集群,它和gitlab通过api进行通信,所以唯一要求是runner到gitlab是网络通的。
    • 在gitlab上可以在settings中进行配置,可以看到有一些shared runner,但肯定不是我们需要的,我们要自己定制。

以在docker上安装为例,安装配置步骤如下:

sudo docker pull gitlab/gitlab-runner:latest

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
  
sudo docker exec -it gitlab-runner gitlab-ci-multi-runner register  
#提示注册信息,这里最好不采用这种交互式的,因为有一些非必要的配置这里不会出现
# 配置关联gitlab-ci url,在项目settings>CI/CD>runners可以找到
Please enter the gitlab-ci coordinator URL:
# 配置token,在项目settings>CI/CD>runners可以找到
Please enter the gitlab-ci token for this runner:
# runner描述,随便输
Please enter the gitlab-ci description for this runner:
# runner的tags,这个很有用,通过tag和jobs关联
Please enter the gitlab-ci tags for this runner (comma separated):

Whether to run untagged builds [true/false]:
# true
Please enter the executor: docker, parallels, shell, kubernetes, docker-ssh, ssh, virtualbox, docker+machine, docker-ssh+machine:
# docker
Please enter the default Docker image (e.g. ruby:2.1):
# maven:3.7.9-jdk-8

coordinator URL和token位置如下

深度截图_选择区域_20200426215130

gitlab ci工作原理

从前文中我们已经知道,有以下几个角色

  • gitlab
  • runner
  • executor
    • gitlab触发条件后,会通知给对应的runner,runner并不是命令执行者,而是类似一个调度器或者说中介,真正干活的是executor,我们完全可以构建自己的executor来满足我们的CI需求。比如通过docker自定义容器实现(docker是个好东西)。

我们的CI/CD方案

因为我们产品上线是在公司有严格控制的,所以CD中最后一步“部署上线”肯定是满足不了的,策略就是从提交代码开始,到测试环境的部署测试。结合实际项目情况,方案图例如下

深度截图_选择区域_20200426220852

首先只有mr动作触发我们的pipeline,进行单测,单测通过后部署到测试环境中,然后跑自动化测试,都通过后,由代码reveiwer惹怒元不能自动化的新功能新需求,通过后补充手动测试,QA确认通过后整个流结束。