https://mp.weixin.qq.com/s/vX4FVQIynLPl68QYiIcspA
说到GitLab你也许听说过，它是类似于GitHub的Git仓库管理工具，不同的是它有开源社区版本，可以方便的部署私服。
从 GitLab 8.0开始，GitLab CI就已经集成在GitLab 中，只需在项目中添加.gitlab-ci.yml文件并设置好Runner便可进行持续集成。而且随着 GitLab 的升级，GitLab CI 变得越来越强大并发展向CD及全生命周期。
本文将介绍GitLab CI/CD以及浅尝实践。
CI/CD
关于CI/CD，在我之前的文章“《从devops看自动化发布》”中介绍过，它是一种持续交付的软件开发实践，简化开发之后到部署完成这段固定的过程。当自动化在工作流中占比较大时能有效提升交付速度。持续集成方法基于自动执行脚本，最大程度地减少开发阶段引入错误的机会。
从开发新代码到部署新代码，几乎不需要人工干预，甚至根本不需要干预。该过程涉及到在每次小的迭代中就不断地构建、测试和部署代码更改，从而减少了基于已经存在bug或失败的先前版本开发新代码的机会。
GitLab CI/CD
GitLab CI/CD是GitLab提供的一套自动化构建、测试和部署的解决方案，其作用是帮助团队实现持续集成和持续交付，使开发人员能够快速交付和修复问题，它由Runner、Pipeline、Stage、Job、Artifact、Environment、Trigger等部分组成。
GitLab CI/CD依赖于GitLab平台，所以我部署了一套GitLab CE用于测试。
Pipeline
一次Pipeline就是一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。任何提交或者Merge Request的合并都可以触发Pipeline，它是一组运行在各个Stage中的Job集合。图片
Stages
Stages表示构建阶段，可以在一次Pipeline中定义多个Stages，这些Stages会有以下特点：
所有Stages会按照顺序运行，one by one；
所有Stages完成后，构建任务(Pipeline)才会成功；
任何一个Stage失败，后面的Stages不会执行，该构建任务(Pipeline)失败。
Stages和Pipeline关系如图：图片
Jobs
Jobs表示构建工作，表示某个Stage里面执行的工作。我们可以在一个Stages里面定义多个Jobs，这些Jobs会有以下特点：
相同Stage中的Jobs会并行执行；
相同Stage中的Jobs都执行成功时，该Stage才会成功；
如果任何一个Job失败，那么该Stage失败，即该构建任务(Pipeline)失败。
Jobs和Stage关系如图：图片
GitLab Runner
GitLab Runne用于构建任务，即上面提到的任务、阶段、工作，都由Runner来执行。
为什么不是GitLab CI来运行那些构建任务？
一般来说，构建任务如编译代码会占用很多的系统资源，而GitLab CI是GitLab的一部分，如果由GitLab CI来运行构建任务的话，在执行构建任务的时候GitLab的性能会大幅下降。
GitLab CI最大的作用是管理各个项目的构建状态，所以运行构建任务这种浪费资源的事情就交给 GitLab Runner 来做了。因为GitLab Runner可安装到不同的机器上，所以在构建任务运行期间不会影响到GitLab的性能，也可理解为是一种解耦设计。
安装Runner
部署Gitlab及安装开发环境过程就略过了，直接从部署Runner开始实践部分。我的主机环境是CentOS，按照官方文档如下安装：
curl -LJO https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_amd64.rpm
rpm -i gitlab-runner_amd64.rpm
gitlab-runner register
sudo gitlab-runner register
注册Runner
注册Runner需要提供GitLab项目的一些信息，可以Settings的CI/CD页面展开Runners找到：
图片
图片
- 输入URL
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com) http://example.com:1234/ - 输入Token
Please enter the gitlab-ci token for this runner ASDFGHJKL123456 - 输入描述
`asp
Please enter the gitlab-ci description for this runner
vm-centos7-runner
4. 输入 tag
```asp
Please enter the gitlab-ci tags for this runner (comma separated):
my-runner- 输入 Runner 执行器
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell: shell
编写 .gitlab-ci.yml
配置好Runner之后，接下来要做的事情就是在项目根目录中添加.gitlab-ci.yml文件了。
当我们添加了.gitlab-ci.yml文件后，每次提交代码或者合并MR都会自动运行构建任务，实际上该配置就是在定义Pipeline。
我们的测试项目编写.gitlab-ci.yml如下：
stages:
- build
- deploy
cache:
paths:
- target
build-job:
tags:
- my-runner
stage: build
script:
- mvn -DskipTests=true clean package
artifacts:
name: "jar"
paths:
- target/demo-0.0.1-SNAPSHOT.jar
deploy-job:
tags:
- my-runner
stage: deploy
script:
- cp target/demo-0.0.1-SNAPSHOT.jar /usr/local/demo/
- cd /usr/local/demo
- java -jar demo-0.0.1-SNAPSHOT.jar
建立测试项目
从start.spring.io创建一个SpringBoot应用如下：
图片
然后用idea打开项目后，随意编写一个测试接口：
@Slf4j
@RestController
public class HelloController {
@RequestMapping("/hello")
public String getHello(){
return "hello!";
}
}pom修改如下：
修改编译java版本
<properties>
<java.version>1.8</java.version>
</properties>需添加如下依赖：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.9.2</version>
<scope>test</scope>
</dependency>代码上传至gitlab即可触发CI/CD流程，在pipeline中可查看具体执行情况：
$ git add .
$ git commit -m "pom-junit"
$ git push验 证
在runner运行成功通过后即可进行验证，访问http://ip:port/demo/hello即可看到返回”hello“。在Gitlab中可看到该任务的执行状态：
图片
1）One more thing
Runner运行权限如果不够，需要给gitlab-runner用户root权限：
$ usermog -aG root gitlab-runner或者直接chown gitlab-runner:gitlab-runner /usr/local/demo/
PS:.gitlab-ci.yml中需给job指定tags否则可能找不到runner而不执行CI。
2）优势
与其他devops工具相比，GitLab CI/CD有以下几个优势：
GitLab CI/CD与GitLab平台紧密集成，CI/CD高效和稳定。
GitLab 提供与第三方服务的更多原生集成，包括云提供商、部署平台和监控工具。
GitLab 以其快速可靠的性能而闻名。它具有内置的缓存和并行处理功能，使开发人员能够快速高效地运行他们的管道。
GitLab 具有内置的安全功能，可确保代码在每个管道阶段都是安全的。它提供代码扫描、漏洞管理和容器扫描等功能，可帮助开发人员在将其投入生产之前识别和修复安全问题。
