第七章：敏捷开发工具方法-part2-CI/CD工具介绍

前言

什么是CI/Cd？

CI-Continuous integration： 持续集成是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代吗行合并到一起并切相互不影响工作。
CD-continuous deployment：持续部署是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品,持续部署在某种程度上代表了一个开发团队的更新迭代速率。
Continuous Delivery: 持续交付是在持续部署的基础之上，将产品交付到线上环境，因此持续交付是产品价值的一种交付，是产品价值的一种盈利的实现。

• 持续交付并不是指软件每一个改动都要尽快的部署到产品环境中。它指的是任何的修改都已证明可以在任何时候实施部署。 持续
• 交付(Continuous Delivery)是一系列的开发实践方法，用来确保让代码能够快速安全的部署到产品环境中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。因为使用完全的自动化过程来把每个变更自动的提交到测试环境中，所以当业务开发完成时，你有信心只需要按一次按钮就能将应用安全的部署到产品环境中。

特点：

• 通常将侧重研发侧的过程称为CI(持续集成)，侧重正式环境部署的过程称为CD(持续交付)
• 一般不单独提持续部署(ContinuousDeployment)
  

主要工具：

• 代码仓库:Git进行管理;静态检查;Sonar集成
• 单元测试:Junit;单测覆盖率
• JaCoCo插件;编译打包;
• 集成部署: she11脚本/服务接口;
• 自动化测试:RobotFrameWork，
• 自动化测试平台;CI报告;Sonar。
• Gitlab+Jenkins+SonarQube+阿里EDAS平台+RF自动化测试套件等.

一、CI-持续集成

Martin Flowler对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建 (包括编译，部署，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

常用工具：

• 代码管理：gitlab(企业自建），gitee(企业租户形式使用）
• 持续集成：jenkins

1.1 安装部署gitlab

• 官网：官网，中文官网
• 注意：建议安装的gitlab在虚拟机中至少给到2G以上内存，不然可能会安装不成功，卡在某个地方报错
  
  1、下载镜像
  由于官网镜像太慢，所以在国内开源镜像站中查找。如：清华大学开源软件镜像站
• 搜索gitlab镜像（目前使用社区版），下载最新。镜像列表地址：https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/
  

2、登录服务器，下载镜像

# 下载
wget https://mirrors.tuna.tsingua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-14.9.4-ce..el7.x864.rpm
# 安装邮件服务postfix（gitlab依赖）
yum install postfix
# 启动邮件服务
systemctl start postfix
# 安装gitlab
rpm -ivh gitlab-ce-14.9.4-ce.0.el7.x86_64.rpm
1
2
3
4
5
6
7
8

3、安装完成后，根据提示设置访问地址

# 修改添加gitlab的访问地址
vim /etc/gitlab/gitlab.rb
# 进入gitlab.rb编辑内容中后-----
external_url 'http://192.168.xx.xx:8000'
# :wq 保存并退出编辑----- ip试自身环境定
# 开放端口号
firewall-cmd --permanent --zone=public --add-port=8000/tcp
# 重启防火墙
firewall-cmd --reload
# 查看当前开放端口
firewall-cmd --list-ports
# 重置gitla
gitlab-ctl reconfigure
# 重启gitlab服务
gitlab-ctl restart
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

4、重启完成后，根据external_url访问gitlab

• 当遇到502时，可以尝试多刷新几次
• 如果一直无法访问，就通过gitlab-ctl status查看运行状态
• 登录默认为root，初始密码默认在/etc/gitlab/initial_root_password中查看，登录gitlab后自定设置
  

二、gitlab CI配置

本节假设已建立一个vue3-vite项目的仓库，并在项目根目录新建.gitlab-ci.yml

• gitlab-ci配置的保留字：image(使用docker image)，services(使用docker service),stages(定义工作阶段），types（stage的别名），before_script（在工作任务执行前执行的脚本命令），after_script（在任务执行结束后执行的脚本命令），variables（定义变量）

• 配置文件示例

# stages：是保留字，用于定义工程执行的阶段
stages:
    - build
    - deploy
# build_job： job名称，可以自定义    
build_job:
    stage: build
    script: 
    	- 'echo "start build"'
    	- 'echo "多行输出"'
    
deploy_job:
    stage: deploy
    script: 'echo "start deploy"'
1
2
3
4
5
6
7
8
9
10
11
12
13
14

• 以上只是简单的gitlab-ci配置，而要构建gitlab流水线，需要搭配使用runner，runner的安装一般由管理员部署实现，这里略过了。

三、jenkins实现CI / CD

官网地址， jenkins中文网

3.1 安装jenkins

以centos系统安装为例，官网参考：https://pkg.jenkins.io/redhat-stable/

• 注意：jenkins依赖于java，所以需要先安装java jdk
• 根据官网文档要求，在对应服务器上下载java及jinkins安装包
  

# 安装(已下载jenkins-2.332.3-1.1.noarch.rpm安装包
rpm -ivh jenkins-2.332.3-1.1.noarch.rpm
# 查看jenkins配置文件
vim /etc/init.d/jenkins
# 修改配置（端口或USER，视情况定）
vim /etc/sysconfig/jenkins
# 启动jenkins（首次启动较慢，可能需要四五分钟）
service jenkins start
# 获取初始密码
tail /var/lib/jenkins/secrets/initialAdminPassword
1
2
3
4
5
6
7
8
9
10

解锁jenkins获取初始密码

• 首次启动会推荐安装插件，但安装会耗时很久，所以建议不安装推荐插件，点击“选择插件来安装”后，不勾选插件从而进入下一步。
  
  

• 创建管理员用户
  

• 配置实例（默认不改就好）
  

进入系统后，显示欢迎页：

• 添加中文插件（Manage Jenkins左侧菜单——》Manage Plugins——》available标签页）
  

3.2 配置CI

1、创建新任务并命名

2、关联gitlab仓库
此处需要先安装git插件

在jenkins安装对应服务器上安装git

# 安装
yum install -y git
# 测试安装是否完成
git --version
1
2
3
4

• 配置源码管理
  
• 添加凭据，向下选择是否切换分支
  
• 点击构建，测试是否成功
  

/var/lib/jenkins/workspace是jenkins的默认工作目录，在里面可以看到上一步构建拉取到的项目文件

• 新增构建步骤（进入上一步新建任务的配置中）
  
• 配置shell
  

3.3 配置CD

1、基于上一步的执行shell脚本中，继续添加shell

• jenkins的默认工作路径为/var/lib/jenkins/workspace/DemoTest，但不排除有时不是这个路径，所以可以使用jenkins环境变量的方式来直接进入。
• 项目工程工作路径目录环境变量： $WORKSPACE（Linux环境中），如jenkins安装在windows系统下，则是%变量名%的形式

cd $WORKSPACE
# 安装依赖
npm install
# 打包
npm run build
# 进入打包后目录
cd dist
# 压缩前先删除已有压缩包
rm -f demotest.tar.gz
# 压缩所有文件
tar -zcvf demotest.tar.gz *
# 查看dist目录
ll
1
2
3
4
5
6
7
8
9
10
11
12
13

2、将上一步的压缩包，传到nginx服务器
- 先安装 publish over ssh插件（用于推送压缩包）

• 配置Publish Over ssh (对应nginx服务根目录)
  
  
• 添加构建后操作
  
• 添加构建后操作配置（注意：对应nginx服务器上已创建demotest文件夹的前提下，且配置了nginx对demotest路径的配置）
  

3.4 其他构建方式

1、定时构建

1、打开demotest任务的配置，切到构建触发器

2、指定参数构建

1、安装git parameter插件

2、修改任务配置——勾选“参数化构建过程”

3、添加Git参数配置

4、修改“源码管理”处的指定分支

5、查看可用构建的标签和分支（选中后，点击开始构建即可）

3、webhook自动根据git事件进行构建

1、添加插件

2、打开demotest配置（在安装gitlab插件后，会新增一个构建触发器选项如下）

3、到gitlab中配置出站请求（gitlab群组管理中设置）
设置——》网络——》出站请求

4、设置webhooks（对应代码仓库中设置）

5、测试push event