CI/CD介绍

持续整合（英语：Continuous integration，缩写CI），又译为持续集成，是一种软件工程流程，是将所有软件工程师对于软件的工作副本持续集成到共享主线（mainline）的一种举措。该名称最早由葛来迪·布区（Grady Booch）在他的布区方法中提出，在测试驱动开发（TDD）的作法中，通常还会搭配自动单元测试。持续集成的提出主要是为解决软件进行系统集成时面临的各项问题，极限编程称这些问题为集成地狱（integration hell）。持续集成的宗旨是避免集成问题，如同在极限编程(XP)方法学中描述的集成地狱。持续集成并非普遍接受是用来改善集成频率的方法，因此重要的是区分两者所带来的效益。
简言之，在一段时间内，将所有开发人员的代码合并到一个共享的主干里，每次合并都会触发持续集成服务器进行自动构建，这个过程包括了编译、单元测试、集成测试、质量分析等步骤，结果只有两个：成功或者失败。如果得到失败的结果，说明有人提交了不合格的代码，这就能及时发现问题。
持续交付（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
持续部署（英语：Continuous deployment，缩写为CD），是一种软件工程方法，意指在软件开发流程中，以自动化方式，频繁而且持续性的，将软件部署到生产环境（production environment）中，使软件产品能够快速的发展。

使用Jenkins创建自动部署任务

配置Jenkins插件

因为我们需要让JenKins自动拉取代码仓库的项目，所以需要一些插件来帮助我们进行与代码仓库的连接，以下将会以代码仓库为GitLab基础进行配置。
首先我们需要进入到Jenkins的插件管理界面
针对于GitLab，我们需要安装一下几个插件
- GitLab API Plugin
- GitLab Authentication plugin
- GitLab Plugin
- Git
此时，我们已经具备可以连接GitLab的条件，接下来由于我们需要让JenKins具备可以向目标服务器传输构建完的结果文件，以及构建完成后需要执行的操作，所以我们需要再次安装Publish Over SSH插件。
PS：如果因网络问题无法从Jenkins默认的安装源进行插件的下载，可更换国内镜像源。Dashboard -> 系统管理 -> 插件管理 -> Advanced settings 更改升级站点的URL即可。
国内镜像源地址：

配置项目构建环境

以RuoYi单体项目为例，我们需要在JenKins里配置Maven的安装路径。JenKins既支持自定义Maven的安装路径，也可以设置自动安装Maven。
Dashboard -> 系统管理 -> 全局工具配置在最下方的Maven安装，点开下拉菜单自定义好名称，勾选自动安装选项并指定所要安装的版本，单击保存即可安装。
如果服务器已存在现有Maven环境或者想自行安装Maven环境，可以在Dashboard -> 系统管理 -> 全局工具配置在最下方的Maven安装，点开下拉菜单自定义好名称，但不要勾选自动安装，在下方的MAVEN_HOME填入服务器Maven的安装路径，单击保存即可。
然后，我们需要配置与代码仓库的连接与认证。以GitLab为例，Dashboard -> 系统管理 -> System 找到GitLab菜单项，新增一个GitLab连接。在弹出的表单列表内输入自定义的连接名称，代码仓库系统的地址以及访问凭据即可。如果需要允许每个Jenkins作业使用单独的身份验证凭据，需要勾选Enable authentication for '/project' end-point。

配置自动部署任务

我们先尝试最简单的通过设置各个菜单项的方式完成一条自动部署任务。
首先在Dashboard页面，单击新建任务，自定义一个任务名称。由于我们是为Maven项目创建自动构建部署，所以这里我们选择构建一个Maven项目。
创建完成后，我们进入到部署工作流的设置界面，在General菜单里，我们可以对这个任务自定义描述、选择指定的GitLab连接项，以及根据具体需求进行设置构建条件等。具体可以单击?查看详细介绍。
在源码管理菜单项，我们勾选Git，在弹出的表单中，设定我们需要拉取的代码仓库git链接、凭据、构建分支等参数。
设置完git仓库后，我们进入到构建触发器，也就是与GitLab进行联动的核心设置。如果我们需要达成在GitLab接收到push、merge等操作，自动发送请求触发Jenkins启动项目构建任务，首先我们需要将JenKins生成的Webhook URL部署到GitLab上面。
我们复制完成Webhook URL后，我们进入到GitLab的这个项目下，在左侧设置菜单下，进入到集成子菜单。
在添加集成的菜单列表中找到JenKins，点击配置按钮，进入到JenKins集成配置界面。我们可以根据需求进行启用该集成，配置触发器类别。然后，将我们刚才复制下来的URL粘贴到Jenkins 服务器 URL输入框内。设置好Jenkins的用户名和密码，如果Jenkins没有使用SSL，不要勾选启用SSL验证。单击测试设置，如果通过即可点击保存。
PS：这里需要注意一点，如果你的Jenkins与GitLab部署在相同服务器内，需要进入GitLab管理中心的设置菜单内，进入到网络页面，展开出站请求菜单列表，勾选允许来自 webhooks 和集成对本地网络的请求。否则，webhook将无法与Jenkins进行通信。
完成Webhook配置后，我们回到Jenkins继续配置构建触发条件。我们可以根据需求决定在push、merge、分支操作等进行构建。
在Build菜单里，我们可以设置项目的根pom.xml位置，以及Maven环境变量，Maven settings file等文件的位置，根据项目需求自行设定。
至此Maven构建部分配置完毕，之后我们需要将打包好的jar传输到我们的目标服务器也就是项目运行服务器中。
首先我们需要配置一下目标服务器的凭证。Dashboard -> 系统管理 -> System ，找到下方的Publish over SSH，添加一个SSH server，自定义目标服务器的名字，然后输入目标服务器的地址和用户名、凭证（展开高级菜单，选择密码或者公私钥）
回到构建任务配置界面，找到构建后操作下的Send build artifacts over SSH，选择刚才设置的SSH连接名称，在Transfers菜单里，主要设置的是文件传输的一些配置。
Source files：主要是配置需要上传到目标服务器的文件，支持通配符。
Remove prefix：不应在远程服务器上创建的文件路径的第一部分。目录结构是相对于基目录（通常是工作区）创建的。您通常不希望在服务器上创建这些文件的完整路径。例如，如果源文件是，则您可能希望 Remove prefix 为这将在远程目录下创建 images 文件夹，而不是 target/deploymentJenkins 环境变量可以在此路径中使用。target/deployment/images/**/target/deployment，如果使用 remove 前缀，则所有源文件路径都必须以前缀开头。
Remote directory：传输到目标服务器的目录，一般是默认在Linux用户目录下再创建一个Remote directory指定的目录。
Exec command：文件传输完成后需要执行的shell

至此，我们基本上完成了GitLab接收到指定代码变更操作后，通过Webhook请求Jenkins进行项目拉取及构建，并将构建结果发送到目标服务器以及启动项目的整套流程。
后续还会涉及在构建过程中进行代码扫描以及将Jenkins构建过程状态通过Pipeline返回给GitLab。这些会在接下来的文章中继续介绍。