DevOps系列文章 之 SpringBoot整合GitLab-CI实现持续集成

在企业开发过程中，我们开发的功能或者是修复的BUG都需要部署到服务器上去，而这部分部署操作又是重复且繁琐的工作，GitLab-CI 持续集成为我们解决了这一痛点，将重复部署的工作自动化，大大的节省了程序员们的宝贵时间。本文详细讲述了 GitLab-CI 持续集成的安装、部署、以及配置。

文中的工具包有需要的话也可以私信博主哟~

一、概述

1.1、什么是CI/CD

CI/CD 属于 DevOps，代表持续集成、持续交付/部署。CI/CD 自动化了传统上将新代码从提交到生产（例如构建、测试和部署）以及基础设施配置所需的大部分或全部手动人工干预。借助 CI/CD ，开发人员可以对代码进行更改，然后自动测试并推出以进行交付和部署。以实现停机时间最小化，代码发布速度更快。

1.2、持续集成(CI)

持续集成是在提交或合并代码时，自动测试每个更改，并自动启动构建。可以大大减少开发和运维人员的重复工作，可以在软件开发生命周期的更早阶段更轻松的发现并修复错误和安全问题。

1.3、持续交付(CD)

持续交付是一种软件开发实践，一般与持续集成结合使用，以自动化基础设置供应和应用程序发布过程。

一旦代码作为 CI 流程的一部分进行了测试和构建，持续交付将在最后阶段接管，以确保可以随时部署并将部署所需要的环境打包在一起。

通过持续交付，可以随时将构建的软件部署到生产环境。可以手动触发部署，也可以进行自动化部署。

二、CI/CD流水线

2.1、Pipeline

Pipeline 相当于构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。

任何提交或合并代码都可以触发 Pipeline。

2.2、Stages

Stages 表示构建阶段，可以在一次 Pipeline 中定义多个 Stages。

Stages 有以下特点：

• 所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始
• 只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功
• 如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败

2.3、Jobs

Jobs 表示构建工作，表示某个 Stage 里面执行的工作。可以在 Stages 里面定义多个 Jobs。

Jobs 有以下特点：

• 相同 Stage 中的 Jobs 会并行执行
• 相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功
• 如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败

2.4、Runners

Runner 是一个在 GitLab CI/CD 管道中运行作业的应用程序。简而言之，就是由 Runner 来执行这些构建任务。

GitLab Runner 可以安装到不同的机器上，也可以在容器或 Kubernetes 集群中运行。Runner 在安装机器上处理作业，在构建任务运行期间并不会影响到 GitLab 的性能。

三、安装GitLab Runner

3.1、环境准备

创建目录

1	mkdir -p /usr/local/docker/runner

1	mkdir -p /usr/local/docker/runner/environment

下载 jdk-8u341-linux-x64.tar.gz、apache-maven-3.5.3-bin.tar.gz、settings.xml、docker-compose，并将其上传至 environment 目录

1 2 3 4 5 6 7 8

$ ll total 197168 drwxr-xr-x 2 root root      4096 Dec  3 20:13 ./ drwxr-xr-x 3 root root      4096 Dec  3 20:13 ../ -rw-r--r-- 1 root root   8799579 Dec  3 20:13 apache-maven-3.5.3-bin.tar.gz -rw-r--r-- 1 root root  44924928 Dec  3 20:13 docker-compose -rw-r--r-- 1 root root 148162542 Dec  3 20:13 jdk-8u341-linux-x64.tar.gz -rw-r--r-- 1 root root     10596