gitlab CI/CD学习笔记

最近我们团队准备用gitlab的cicd功能提升工作效率，这里做一些记录。

一、CI/CD 介绍

「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」三个概念的认识

持续集成

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

持续交付

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

持续部署

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

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

说白了，持续交付就是自动地从仓库将最新的程序部署到测试环境里，持续部署就是自动地将稳定版本部署到生产环境里；

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

CI/CD流程

一般每个团队不一样，这里提供一种思路：

ci/cd流.png

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

常见CI/CD工具

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

gitlab ci 项目的url和token

gitlab ci工作原理

从前文中我们已经知道，有几个角色：

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

三、我们的CI/CD方案（拟）

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

方案图.png

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

gitlab ci可以和jenkins进行集成，这个后面再讨论。