GitLab持续集成持续部署(CI&CD)

导读:本篇文章讲解 GitLab持续集成持续部署(CI&CD),希望对大家有帮助,欢迎收藏,转发!站点地址:www.bmabk.com

其他博文连接

GitLab CI/CD介绍

首先使用一张图说明GitLab CI的工作流程:
这里写图片描述
GitLab CI是 GitLab 提供的持续集成服务,只要在你的仓库根目录 创建一个.gitlab-ci.yml 文件, 并为该项目指派一个Runner,当有合并请求或者 push的时候就会触发build。

这个.gitlab-ci.yml 文件定义GitLab runner要做哪些操作。 默认有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脚本来操作。因为水平有限,如果有问题可以提出,学习交流。

参考资源

  • https://www.jianshu.com/p/705428ca1410
  • https://docs.gitlab.com/runner/

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/13139.html

(0)
小半的头像小半

相关推荐

极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!