目录
4.1.3 GitHub Actions持续集成技术实现原理
4.1.3.1 GitHub Actions工作流程构成关系图
4.2 基于Jenkins/GitLab CI的持续集成流水线（私有云）
4.2.3 Jenkins+GitLab持续集成技术实现原理
一、概述
介绍完了持续集成基本概念和包含的主要系统，接下来将从平台建设和技术实现的角度为大家详细讲述其典型流程下的技术细节。
二、持续集成的典型操作流程
2.1 概述
持续集成流程在DevSecOps平台中主要表现为持续集成流水线，在实际的平台建设中，这一段流程的线上化过程通常是分阶段、分步骤实现的。大多数情况下，首先实现的是代码管理到集成测试这一段的线上化，然后再通过安全左移，逐步完成整个持续集成到持续开发的线上化。
2.2 持续集成的操作流程图
当整个流程完成线上化之后，在DevSecOps平台中，编排调度系统是持续集成平台能力的核心，承担着流程调度、任务管理和面向用户交互的职责。基于日常的研发操作和上文中提及的持续集成流程中涉及的主要系统，其典型操作流程如下图所示：
2.3 持续集成关键流程说明
其关键流程如下：
- 当开发人员完成开发后，提交代码至代码存储仓库。
- 触发源码及版本控制系统事件HOOK，发起代码编译构建动作。
- 编译构建系统拉取源代码，开始代码编译。
- 依次执行代码编译、制品打包、静态检测。
- 当上述步骤执行通过后，通过调度将制品上传至过程制品库。
- 生成的过程制品将被部署在资源及环境管理系统准备好的研测环境上。
- 制品部署完成后，进入测试阶段，依次完成集成测试、安全测试、回归测试。
- 当测试阶段动作全部完成后，将验证后的制品上传可发布制品库，供生产环境发布使用。
在整个过程中，各个任务在流水线上依次递进，直至将代码转化为可交付的制品，这就是DevSecOps平台中持续集成流程的核心作用。
三、构建持续集成流水线的方式
当一家企业着手搭建持续集成流水线时，通常可以使用如下三种不同的方式去构建此能力
3.1 依托云厂商能力
依托云厂商能力，即利用云厂商SaaS化持续集成相关系统或服务，构建企业自身的持续集成流水线。
3.2 采用开源产品
采用开源产品，即企业通过整合开源的持续集成相关产品，构建本地化的持续集成流水线。
3.3 企业自研
企业自研，即企业通过独立研发持续集成相关产品，构建本地化的持续集成流水线。
上述三种平台能力构建方式中，企业自研的方式更适用于大型互联网企业的大规模并发的持续集成场景，当然需要的资源投入和实施周期也不一样。考虑本书内容的普及性和实用性，这里主要以前两种方式为例向读者介绍持续集成流水线平台能力的搭建。
四、构建持续化集成流水线
4.1 基于GitHub的持续集成流水线（公有云方案）
4.1.1 概述
基于GitHub的持续集成流水线适合中小型互联网企业，或者说使用公有云基础设施及源代码云托管服务的企业。这类企业有一个典型的特点是代码管理托管在云服务上（这里主要是指GitHub），企业大多数没有自己的数据中心，采购云厂商的云主机、云数据库、云存储等作为企业的基础设施，如研测环境和生产环境均在公有云上。
4.1.2 GitHub持续集成方案操作流程示意图
GitHub Actions是GitHub平台上的一个功能模块，在代码托管的基础上可以承担持续集成流水线的功能，用户通过GitHub Actions对软件开发流程的定义，自动化地帮助用户完成代码检出、编译构建、代码检测、依赖管理、测试、部署等操作。当基础设施使用公有云时，在此持续集成方案的基础上，可以快速方便地完成持续部署的自动化。此方案的操作流程概览图如下图所示：
从图中可以看出，当使用GitHub作为持续集成流水线控制时，GitHub Actions担当着总体流程调度的角色，当触发工作流程的事件后，流程启动开始执行。
4.1.3 GitHub Actions持续集成技术实现原理
4.1.3.1 GitHub Actions工作流程构成关系图
使用GitHub Actions来实现持续集成时，工作流程是通过在GitHub上定义的YAML文件来描述的。YAML文件一般存放在.github/workflows目录中，一个项目可以定义多个YAML文件，一个YAML文件定义一个流程(Workflows)，流程由事件(Event)触发作为入口。一个流程包含多个不同的任务(Job)，每一个任务由一个或多个步骤(Step)组成，每一个步骤可以执行一个或多个操作(Actions)。Workflows-Job-Step-Actions它们组装在一起，构成整个工作流程，如图所示：
配置完成的工作流程可以通过手工操作、GitHub CLI、API接口等方式触发流程启动事件。事情启动后，会依次执行每一个任务，直至流程结束。如果流程执行失败，GitHub Actions也会起到监控和调度的作用。
4.1.3.2 GitHub Actions工作流程
4.1.3.2.1 新建Actions
当用户代码托管在GitHub后，可以在项目中的Code标签页直接新建Actions，如图所示:
4.1.3.2.2 自定义工作流程
进入页面后，单击New workflow的按钮，开始定义工作流程。默认情况下，当前页面提供了一系列的工作流程模板，如推荐的模板列表、持续集成的模板列表、安全检测的模板列表等。同时，用户也可以自定义自己的工作流程。
在上图中，
❶所示位置为用户自定义工作流程入口，
❷所示位置为系统推荐的工作流程模板入口。
4.1.3.2.3 选择快捷模板
当然，用户还可以选择其他的工作流程的快捷模板，如下图所示：
4.1.3.2.4 进入配置页面
这里选择GitHub Actions工作流程后，则进入YAML文件的配置页面，如下图所示：
在上图中，
❶所示区域为YAML文件的自定义配置编辑区，
❷所示区域为GitHub根据应用市场的使用情况推荐给用户的操作模板和说明文档。用户参考操作模板和说明文档完成YAML文件的自定义编辑之后，修改❸的文件名，最后单击❹Start commit按钮提交YAML文件，提交后在代码项目“根目录/.github/workflows”下会存在刚才提交的YAML文件。
至此，工作流程的定义已完成。当代码仓库发生变化时，如果发现“根目录/. github/workflows”下存在yml文件，将根据流程触发条件，启动流程。
4.1.3.3 举例配置Node.js YAML文件
在整个工作流程中的定义中，YAML文件的配置是流程定义关键。下面以一个Node.js项目为例介绍持续集成配置，其文件样例如下图所示：
在上图中，文件主要包含三个部分：
❶表示整个流程的名称，
❷表示流程的触发条件为事件push，
❸表示要执行的任务内容。
其中
❹表示使用代码的主分支master，
❺表示任务主要是编译构建与测试，
❻表示编译构建和测试的使用环境为Ubuntu操作系统，
❼表示当前Job任务所包含的步骤，
❽~11均为其操作步骤：
❽表示代码Checkout操作，
❾表示命令行环境下依赖环境的安装、构建和测试操作，
10表示对dist目录下的文件排除txt类型之后生成的制品上传
11表示上传自动化测试报告。
这是一个简单的Node.js项目持续集成样例，在实际使用中，开发语言不同，使用场景不同，流程的定义往往要复杂得多。但通过这个样例，读者能概要性地了解GitHub Actions实现持续集成流程的基本逻辑。
4.1.3.4 总结
对于GitHub Actions的使用GitHub官方文档中有比较详细的描述，感兴趣的读者可以详细阅读其案例，并动手操作，理解不同场景下的持续集成流程的定义和使用。
例如，GitHub上Action的代码仓库包含各种流程定义模板，感兴趣的读者可以访问地址：
GitHub - actions/starter-workflows: Accelerating new GitHub Actions workflows
同时，在GitHub的应用市场上也有非常多的使用案例，这些案例，既包含持续集成能力，也包含安全能力（如下图所示）；
既包含GitHub自身功能，也包含其他厂商的SaaS化能力，如亚马逊AWS、阿里云、RedHat等（如下图所示）。
这些与GitHub可集成的能力，对于使用GitHub实现持续集成流水线的企业来说，无疑是极大地缩短了DevSecOps能力构建的周期，降低了平台学习和平台使用的成本。
4.2 基于Jenkins/GitLab CI的持续集成流水线（私有云）
4.2.1 概述
基于Jenkins或GitLab CI去构建企业级持续集成流水线是业界非常普遍的方案，这与它们本身的开源、易于操作，满足常见持续集成场景下各个任务的调度需求有关，同时也与周边生态系统的成熟，与版本管理工具、版本控制工具、构建工具等易于集成也有很大的关系。用户通过使用此类方案，可以方便、一揽子地解决多个业务操作和系统数据之间的打通与联动。
除了少数大规模、高并发的大型互联网企业需要自己去研发流程调度系统外，在使用已有的开源产品或商业产品来构建持续集成能力时，Jenkins通常是企业的首选方案。
4.2.2 Jenkins持续集成方案操作流程示意图
Jenkins是基于Java语言的企业级持续集成工具，可以持续、自动化、分布式完成持续集成流程中的多个任务，如构建、测试、监控等。以Jenkins为流程调度的持续集成流水线，其概览图如下图所示：
从此方案中可以看到，图中编译、打包、镜像构建、上传镜像、删除镜像等操作，都是在Jenkins统一调度下完成的，Jenkins通过API接口、脚本、应用等调用，完成持续集成流程中的关键任务。它与基于GitHub持续集成方案的不同在于，此方案中代码托管在本地环境，管理工具使用的是Git和GitLab，Jenkins、Docker仓库、测试环境等也都是企业自己搭建的，整个平台具有很好的自主性和可定制性。
4.2.3 Jenkins+GitLab持续集成技术实现原理
4.2.3.1 说明
接下来，将以Jenkins+GitLab相结合的方案介绍持续集成能力的实现。Jenkins+GitLab的安装市面上有很多文字资料和视频，这里仅做简要地介绍，通过简化安装让读者了解其系统构成即可。
4.2.3.2 安装GitLab
GitLab是业界使用比较广泛的一款覆盖DevSecOps全流程的软件，它分为GitLab CE和GitLab EE两个版本，其中GitLab CE为社区的开源版本，GitLab EE为企业级版本，企业版有一定时间的免费试用期。这里以GitLab CE版本为例，讲述GitLab的安装。GitLab安装有多种安装方式，常见的有使用已下载安装包安装、在线安装，如Linux环境下rpm包安装，yum在线安装、Docker安装等。使用yum安装时，需要注意的是，安装时需要考虑到网络速度的传输。建议选择安装源时，首选考虑国内的安装镜像源，如清华大学开源软件镜像源、科大镜像源、华为镜像源等，如下图所示：
本文为了简化GitLab的安装操作，方便读者快速使用和了解GitLab，使用Docker化安装方式。Docker安装首先要下载GitLab，如下命令行所示：
待此命令执行完成后，即可启动GitLab，如下命令行所示：
等待一段时间，当所有的容器状态正常时，即可以通过gitlab.devsecops-demo.com访问GitLab。如果通过域名无法访问，读者需要配置IP解析。首次使用时，需要配置GitLab管理员密码，设置完密码后才可以管理员身份登录GitLab。
相比yum安装，Docker的安装与配置要简单得多，读者也可以使用其他方式安装，来加深对GitLab的理解。另外，对于英文不好的读者，建议安装时选择中文版，即选择镜像gitlab-ce-zh:latest即可，其他步骤与英文版一致。
4.2.3.3 安装Jenkins
Jenkins是Java语言开发的，所以安装之前先查看本机是否已安装JDK，如果没有安装则需要首先安装JDK。本文默认JDK已正确安装，如果有读者不知道JDK如何安装，请查阅相关资料。这里仍以Docker环境为例，讲述Jenkins的安装过程。
在Docker命令行模式下，执行以下命令：
默认情况下，使用latest镜像。待此命令执行完成后，即可启动GitLab，如下命令行所示：
等命令行执行完成后，即可通过jenkins.devsecops-demo.com访问页面。这里需要读者注意的是，GitLab的Docker启动参数与Jenkins的启动参数在端口上要避免冲突，并且和GitLab安装一样，考虑jenkins.devsecops-demo.com与IP地址的解析。否则也是无法访问的。
首次访问Jenkins需要解锁管理员密码，这时只需要进入Jenkins HOME目录查询密码复制输入即可，如下图所示：
解锁完成后，即可登录进系统，参考新手入门的指引，创建用户、添加插件及执行相关配置。
4.2.3.4 GitLab配置访问令牌
GitLab配置访问令牌，并通过令牌与Jenkins之间进行认证和授权。进入GitLab主界面，进入一个代码仓库后，选择【Setting】→【Access Tokens】，填写Token name：gitlab-jenkins-user-api-token并勾选【api】后，生成令牌信息，如下图所示：
需要将该令牌信息复制下来并保存至安全的位置，后续在Jenkins配置的时候还会使用到该令牌。
4.2.3.5 Jenkins配置
Jenkins主页选择【Manage Jenkins】→【Available】，安装Jenkins GitLab Plugin插件，如下图所示：
选择【Credentials】→【System】→【Global Credentials】→【Add Credentials】，填写GitLab用户令牌，如下图所示：
最后选择【Manage Jenkins】→【Configure System】，选择【GitLab】标签，填入GitLab相关配置，如下图所示：
通过以上四个步骤，已经完成了GitLab与Jenkins的集成。接下来就可以在Jenkins中创建任务进行构建。
好了，本次内容就分享到这，欢迎大家关注《DevSecOps》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！