作者：愤怒的小猿猿

blog.csdn.net/qq_27520051/article/details/80552220

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绑定到一起。

其他系统安装参考

https://docs.gitlab.com/runner/install/linux-manually.html

注册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- testbefore_script:- echo "Restoring Packages..."build_job:stage: buildscript:- echo "Release build..."except:- tagstest_job:stage: testscript:- 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，也可以只填写srcproperties {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_reviewstage: testscript:- 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，也可以只填写srcproperties {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: testscript:- echo "Start reviewing code"- gradle sonarqube

这样在提交代码到远程仓库时即可实现代码审查。结果如下：

进入项目下就可以看到具体的代码审查结果

自动化部署

要实现自动部署，需要在.gitlab-ci.yml中指定执行的脚本，与自动化测试类似。

stages:- deploy
deploy:stage: deployscript:- echo "start deploy....."only:- mastertags:- shell

这里我们只有一个stage是deploy。only指定了只有在master分支push的时候才会被执行。tags是shell，对应了刚才注册runner的时候的tags。
这是一个最简单的执行模块，在实际开发中我们要通过一个shell脚本来将资源自动部署到指定位置。例如修改脚本如下：

stages:- deploy
deploy:stage: deployscript:- echo "start deploy....."- deployonly:- mastertags:- 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" ]
thenproject_url="http://XXXXcom/xuda/gitlab_ci_cd_test.git"git clone $project_path $deploy_path
elsecd $deploy_pathgit pull
fi

这个脚本的大意就是，先判断tomcat的webapps下有没有gitlab_ci_cd_test文件夹，如果目录不存在，那么就在webapps文件夹下git clone一个，如果存在了就git pull一个到指定目录下。这样就实现了自动部署，我们同样可以在gitlab的仓库下看到结果

最后，附上一张gitlab仓库的项目结构图

总结

GitLab的持续集成持续部署的功能还是很强大的。因为刚毕业进入这家公司看到他们的持续集成做的非常棒，所以学习了基本的安装。如果想要完成比较复杂的功能也是完全可以实现的，这时可以结合Shell脚本来操作。因为水平有限，如果有问题可以提出，学习交流。

参考资源

• https://www.jianshu.com/p/705428ca1410

• https://docs.gitlab.com/runner/

另琐碎时间想看一些技术文章，可以去公众号菜单栏翻一翻我分类好的内容，应该对部分童鞋有帮助。同时看的过程中发现问题欢迎留言指出，不胜感谢~。另外，有想多了解哪些方面内容的可以留言（什么时候，哪篇文章下留言都行），附菜单栏截图（PS：很多人不知道公众号菜单栏是什么）
END我知道你 “在看”