作者:愤怒的小猿猿
GitLab CI/CD介绍
首先使用一张图说明GitLab CI的工作流程:
GitLab CI是 GitLab 提供的持续集成服务,只要在你的仓库根目录 创建一个.gitlab-ci.yml 文件, 并为该项目指派一个Runner,当有合并请求或者 push的时候就会触发build。
这个.gitlab-ci.yml 文件定义GitLab runner要做哪些操作。默认有3个默认有3个[stages(阶段)]: build、test、deploy。
当build完成后(返回非零值),你会看到push的 commit或者合并请求前面出现一个绿色的对号。这个功能很方便的让你检查出来合并请求是否会导致build失败, 免的你去检查代码。
大部分项目用GitLab’s CI服务跑build测试, 开发者会很快得到反馈,知道自己是否写出了BUG。
所以简单的说,要让CI工作可总结为以下几点:
在仓库根目录创建一个名为.gitlab-ci.yml 的文件
为该项目配置一个Runner
完成上面的步骤后,每次push代码到Git仓库, Runner就会自动开始pipeline。
配置Runner
详细的使用说明,请阅读官方文档:https://docs.gitlab.com/runner/
安装GitLab-Runner
#在ubuntu server16.04版本下使用命令即可安装
$ sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
#接着授予可执行权限
$ sudo chmod +x /usr/local/bin/gitlab-runner
#创建一个gitlab-ci用户
$ sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
#安装,并作为服务启动
$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
至此,安装工作完成,接下来需要注册Runner,来将Runner和Gitlab绑定到一起。
其他系统安装参考
注册Runner
- 输入命令
$ sudo gitlab-runner register
会要求输入gitlab的url和Token.
查找过程如下:
进入仓库->settings->CI/CD,找到Runner Settings这一项,点击Expend,即可在Setup a specific Runner manually
这项中找到。如下:
注意,其他版本位置可能会不同
其中的url和Token就是遮起来的内容,只需要在注册过程中填入即可。
当这些做完之后启用命令启动Runner
$gitlab-runner run
教程上说是使用gitlab-runner
start命令,但我试的时候并没有生效,但是用了gitlab run
就可以了,建议先使用gitlab-runner start
试一下,不行再用gitlab-runner run
启动成功后就可以看到,gitlab对应的仓库下(操作:进入仓库->settings->CI/CD,找到Runner Settings这一项,点击Expend,即可在Setup a specific Runner manually
)看到注册的runner已经在运行了。
注:如果状态颜色是灰色的表示没有运行成功,也可以选择“Pause”和“Remove Runner”
自动化测试
创建.gitlab-ci.yml
.gitlab-ci.yml 介绍
- .gitlab-ci.yml 用来配置 CI 用你的项目中做哪些操作,这个文件位于仓库的根目录。
- 当有新内容push到仓库后,GitLab会查找是否有.gitlab-ci.yml文件,如果文件存在, Runners 将会根据该文件的内容开始build 本次commit。
.gitlab-ci.yml 使用YAML语法, 你需要格外注意缩进格式,要用空格来缩进,不能用tabs来缩进。
创建.gitlab-ci.yml
因为本人项目基本都是Gradle构建的,Gradle进行单元测试比较简单,只需要使用gradle test
即可运行所有的单元测试
- 新建一个.gitlab-ci.yml文件,并完成如下内容
stages:
- build
- test
before_script:
- echo "Restoring Packages..."
build_job:
stage: build
script:
- echo "Release build..."
except:
- tags
test_job:
stage: test
script:
- echo "Tests run..."
- cd cds.ci.test
- gradle test
stage翻译为阶段的意思,在构建的过程中,必须要有一个先后顺序。最上面的stages配置意思是,先构建阶段为build的job,然后再构建阶段为test的job,下面build_job和test_job都是job,如果不配置stages,默认为:
stages:
- build
- test
- deploy
推送配置文件
配置好.gitlab-ci.yml文件之后,只要把它加入git后然后推送到远程仓库,CI就会开始自动化集成。这样我们提交代码到GitLab是在每次提交的后面都会有自动测试的结果
如果失败了,也可以进入对应的阶段,查找错误原因。gitlab提供了可视化的界面,非常方便。
代码审查
安装Docker
- 由于apt官方库里的docker版本可能比较旧,所以先卸载可能存在的旧版本:
$ sudo apt-get remove docker docker-engine docker-ce docker.io
- 更新apt包索引:
$ sudo apt-get update
- 安装以下包以使apt可以通过HTTPS使用存储库:
$ sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common
- 添加Docker官方的GPG密钥
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
- 使用下面的命令来设置stable存储库
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
- 再更新以下apt包索引
$ sudo apt-get update
- 列出可用的版本
$ apt-cache madison docker-ce
- 选取要安装的特定版本
$ sudo apt-get install docker-ce=<VERSION>
SonarQube介绍
安装SonarQube
- 获取postgresql的镜像
$ docker pull postgres
- 启动postgresql
$ docker run --name db -e POSTGRES_USER=sonar -e POSTGRES_PASSWORD=sonar -d postgres
- 获取sonarqube的镜像
$ docker pull sonarqube
- 启动sonarqube
$ docker run --name sq --link db -e SONARQUBE_JDBC_URL=jdbc:postgresql://db:5432/sonar -p 9000:9000 -d sonarqube
- 将sonar-gitlab-plugin-2.1.0.jar添加到docker中的sonarqube容器中
$ docker cp sonar-gitlab-plugin-2.1.0.jar sonarqube:/opt/sonarqube/extensions/plugins
打开http://localhost:9000 点击login
用户名密码均默认为admin
Gradle集成SonarQube
代码审查可以使用Gradle集成Sonarqube。整体来说,共分为三步:
- 在build.gradle中添加配置,启动sonarqube插件
- 配置sonar系统认证权限信息,以便将分析结果上传到sonar中展示;
- 运行分析命令:gradle sonarqube,然后就可以在sonarqube页面上看到分析结果。
但我们需要在gitlab上进行持续集成,所以我们将gradle sonarqube命令写入到.gitlab-ci.yml脚本中,在提交代码到gitlab是执行。
首先对build.gradle进行配置:
buildscript {
repositories {
# 添加库路径,实际项目中原来此处可能还有别的库,在此位置追加。追加库的位置可能会导致项目报错(找不到某些依赖的错误)
maven { url "http://192.168.109.63:8081/nexus/content/groups/public/" }
}
dependencies {
#在此位置追加一下依赖行
classpath "org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:2.6.2"
}
}
plugins {
# plugins段放置位置有要示,放在buildscript段前面会报错,放到文件最末尾也报错,紧跟buildscript放置OK
#添加插件信息
id "org.sonarqube" version "2.6-rc1"
}
apply plugin: "org.sonarqube"
subprojects {
sonarqube {
# 如果同时存在src/main/java与src/main/test,则要按以下方式设置,如果没有单元测试用例目录test,也可以只填写src
properties {
property "sonar.sources", "src/main/java"
}
}
}
#配置sonarqube的权限信息
sonarqube{
properties {
property "sonar.host.url", "http://192.168.90.58:9000"
property "sonar.projectName", "${artifactIdParam}"
property "sonar.projectKey", "${artifactIdParam}"
property "sonar.projectVersion", "${versionParam}"
property "sonar.login","admin"
property "sonar.password","admin"
}
}
完成gradle与sonar的集成后,接下来需要编写.gitlab-ci.yml脚本,增加执行代码审查的脚本。
code_review
stage: test
script:
- echo "Start reviewing code"
- gradle sonarqube
完成之后提交代码到gitlab,即可显示执行结果。
# plugins段放置位置有要示,放在buildscript段前面会报错,放到文件最末尾也报错,紧跟buildscript放置OK
plugins {
#添加插件信息
id "org.sonarqube" version "2.6-rc1"
}
#声明插件
apply plugin: "org.sonarqube"
subprojects {
sonarqube {
# 如果同时存在src/main/java与src/main/test,则要按以下方式设置,如果没有单元测试用例目录test,也可以只填写src
properties {
property "sonar.sources", "src/main/java"
}
}
}
sonarqube{
properties {
property "sonar.host.url", "http://192.168.90.58:9000"
property "sonar.projectName", "${artifactIdParam}"
property "sonar.projectKey", "${artifactIdParam}"
property "sonar.projectVersion", "${versionParam}"
property "sonar.login","admin"
property "sonar.password","admin"
}
}
至此gradle集成SonarQube完成,接下来需要编写脚本并上传
编写.gitlab-ci.yml
在刚才的自动化测试脚本里追加如下内容:
code_review:
stage: test
script:
- echo "Start reviewing code"
- gradle sonarqube
这样在提交代码到远程仓库时即可实现代码审查。结果如下:
进入项目下就可以看到具体的代码审查结果
自动化部署
要实现自动部署,需要在.gitlab-ci.yml中指定执行的脚本,与自动化测试类似。
stages:
- deploy
deploy:
stage: deploy
script:
- echo "start deploy....."
only:
- master
tags:
- shell
这里我们只有一个stage是deploy。only指定了只有在master分支push的时候才会被执行。tags是shell,对应了刚才注册runner的时候的tags。
这是一个最简单的执行模块,在实际开发中我们要通过一个shell脚本来将资源自动部署到指定位置。例如修改脚本如下:
stages:
- deploy
deploy:
stage: deploy
script:
- echo "start deploy....."
- deploy
only:
- master
tags:
- shell
其中deploy是编写的shell脚本,可以实现将要发布的内容自动部署到发布目录下:
#!/bin/bash
deploy_path="/home/xuda/tomcat8/webapps"
project_path="gitlab_ci_cd_test";
judge_path = "$deploy_path/$project_path"
if [ ! -d "$judge_path" ]
then
project_url="http://XXXXcom/xuda/gitlab_ci_cd_test.git"
git clone $project_path $deploy_path
else
cd $deploy_path
git pull
fi
这个脚本的大意就是,先判断tomcat的webapps下有没有gitlab_ci_cd_test文件夹,如果目录不存在,那么就在webapps文件夹下git clone一个,如果存在了就git pull一个到指定目录下。这样就实现了自动部署,我们同样可以在gitlab的仓库下看到结果
最后,附上一张gitlab仓库的项目结构图
总结
GitLab的持续集成持续部署的功能还是很强大的。因为刚毕业进入这家公司看到他们的持续集成做的非常棒,所以学习了基本的安装。如果想要完成比较复杂的功能也是完全可以实现的,这时可以结合Shell脚本来操作。因为水平有限,如果有问题可以提出,学习交流。