一.软件介绍
- Gitlab
- gitlab-runner
- Sonarqube
- sonarqube-scanner
二.Gitlab CI/CD介绍
Gitlab是常用的开源git代码管理工具之一，随着发展推出了ci/cd解决方案，顾名思义具体来说ci/cd主要完成以下两个工作：
- ci(持续构建)：代码提交后触发自动化的单元测试，代码预编译，构建镜像，上传镜像等
- cd(持续发布)：持续发布则指将构建好的程序发布到各种环境，如预发布环境，正式环境。
三.Gitlab CI/CD整体框图介绍
从左往右看，首先研发人员完成需求提交代码到 GitLab。GitLab 触发一次 Build，构建好服务，然后开始跑单元测试、集成测试。等待测试结果通过后，再由负责该项目的同事进行 CodeReview，灰度发布，正式部署到线上。CI/CD 就是指测试和发布环节，如果能够做到自动化，那么就可以大大加快开发迭代的速度。
四.Gitlab + Sonarqube整体框图
五.安装软件
部分一中的软件安装请参考其他教程，这里重点讲gitlab-runner.
- 注册runner
GitLab 中提供了两种 Runner 的类型，上图这个界面可以在 GitLab 项目设置页中找到的，一个是特定的 Specific Runner，另一个是共享的 Shared Runner 。特定的 Runner 只能供部分项目使用，而共享的 Runner 是所有 GitLab 中的项目都可以使用的。而这两种类型的 Runner 的注册方式都是一样。
从注册一个特定的 Runner 开始讲，首先安装一个 GitLab Mutli Runner，因为是 Go 语言实现的，所以安装起来会比较简单，直接采用二进制安装即可。第二步正式开始注册，输入 Gitlab 地址、token、描述、标签执行器等。输入上述数据之后 Runner 就注册好了，由于 Multi Runner 支持动态加载配置，所以 Runner 就立即生效了。可以在刚才的界面中看到新增了一个 Runner。有了 Runner，第二步就是如何在项目中增加 .gitlab-ci.yml 的 CI 配置文件。
六..gitlab-ci.yml介绍
从7.12版本开始，GitLab CI使用YAML文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录，它定义该项目如何构建。
上图所示是一个非常简单的 CI 配置文件。定义了两个阶段，一个 test，一个 build，先执行 test 再执行 build，test 阶段有一个 job 叫做 test，执行的指令是 echo skip，但是这个 job 需要跑在带有 opentalk 的这个标签的 runner 上。build 阶段也有一个 job，叫做 build，它会执行 make docker，去构建 docker 镜像并且推送到私有仓库中，这个任务只有当分支中有 tag 提交才会触发，并且需要跑在带有 online docker builder 的 runner 上。
- stages
stages用来定义可以被job调用的stages。stages的规范允许有灵活的多级pipelines。stages中元素的顺序决定了对应job的执行顺序：相同stage的job是并行执行的；下一个stage的job在前一个stage的job成功完成后才开始执行；如果.gitlab-ci.yml中没有定义stages，那么stages默认定义为build、test和deploy；如果一个job没有指定stage，那么这个任务会分配到test stage。
- variables
variables用来定义变量，全局变量作用于所有job，也可以在指定的job中定义变量（优先级高于全局变量）
如果在job中想禁用全局定义的变量，可通过variables: {}定义一个空的哈希值。
GitLab CI/CD内置变量:
variables | value |
CI_JOB_NAME | 对应的job_name |
GIT_STRATEGY | 指定git获取代码的方式(clone,fetch,none) |
- jobs
jobs用来定义了一组作业，其中必须包含script语句。
variables | 解释 |
job.stage(模式test) | job中指定的stage必须是stages中存在的元素 |
job.tags | 指定该job所允许的Runner，必须在注册Runner时设置Runner的tag |
job.allow_failure | 用于指定该job允许执行失败，则如果执行失败也不影响下一个stage的执行 |
job.script | script是job中必须指定的语句，指定Runner所要执行的命令 |
job.before(after)_script | 指定script执行前/后所执行的命令，也可定义在全局模式，则在所有job中的script执行前后都会执行 |
job.artifacts | 用于指定job执行成功的命令，将会被发送到Gitlab中的文件，且默认情况下job之间会根据stage的优先级自动下载之前所有stage中的artifacts |
artifacts.name | 指定artifact的名称，同时Gitlab上下载的文件名即为artifact_name.zip |
artifacts.when | 指定artifact上传到Gitlab的条件(on_success【默认】,on_failure,always) |
artifacts.expire_in | 指定artifact的过期时间(默认为30天)，使用keep可永久保存 |
job.dependencies | dependencies用于在不同的job之间指定在不同的job之间传递artifacts,dependencies:[]可禁止该job下载artifacts |
job.only;job.except | only和except是两个参数用分支策略来限制jobs构建，only和except可同时使用。如果在一个job配置中同时存在，则同时有效，only和except可以使用正则表达式；only和except允许使用特殊的关键字：branches,tags和triggers |
job.environment | environment用于定义job部署到指定的运行环境中 |
environment.name | 必选，指定environment名称 |
environment.url | 可选，指定environent对应的URL，将在指定的environment页面中添加一个链接按钮指向该URL |
如下是最终的gitlab CI/CD + Sonarqube的配置：
image: sonar
Sonar_Analyze:
script:
- source /etc/environment
- sonar-scanner
tags:
- shell
stages:
- build
- test
- deploy
b1:
stage: build
script:
- echo skip
- uname -a
- make
artifacts:
paths:
- mybinary
tags:
- shell
t1:
stage: test
script:
- echo test
tags:
- shell
d1:
stage: deploy
script:
- echo "Deploy to staging server"
environment:
name: staging
url: https://staging.example.com
tags:
- shell七.整体效果
- gitlab 流水线
- 编译过程
- 静态检查
- 镜像发布
- sonarqube的统计
