目录
一、概述
二、版本控制系统
2.1 概述
2.2 版本控制系统使用流程示意图
2.3 版本控制软件划分
2.3.1 集中式版本控制软件
2.3.2 分布式版本控制软件
2.3.3 总结
2.4 常用版本控制软件介绍
三、编译构建系统
3.1 概述
3.2 编译构建流程示意图
3.3 列举Java 源码编译构建流程
3.3.1 Java代码编译构建流程示意图
3.4 持续集成产品架构分层
3.4.1 持续集成产品架构分层示意图
3.5 常见编译工具列举
四、编排调度系统
4.1 概述
4.2 编排调度系统示意图
4.3 编排调度系统构成内容解析
4.3.1 任务
4.3.2 编排
4.3.3 调度
4.4 编排调度软件举例
4.5 编排调度系统的核心功能
4.5.1 流程编排管理
4.5.2 任务配置管理
4.5.3 作业调度管理
4.5.4 历史日志管理
五、其他系统
5.1 概述
5.2 企业配置管理数据库(CMDB)
5.3 资源管理系统
5.4 制品仓库
5.5 总结
一、概述
了解了持续集成和版本控制的基本概念之后，下面带大家从技术层面深入理解其具体内容。一个标准的持续集成功能通过平台来实现时，它至少包含如下三个部分：
- 版本控制系统。
- 编译构建系统。
- 编排调度系统。
二、版本控制系统
2.1 概述
版本控制系统通常是由版本控制软件和仓库管理软件两部分组成，即业界常说的SCM软件。版本控制软件用来管理代码和项目文件（如SVN），仓库管理软件则基于版本控制软件之上对代码仓库进行管理（如SVNManager）。
2.2 版本控制系统使用流程示意图
在持续集成流程中，版本控制系统承载的操作流程如下图所示。
2.3 版本控制软件划分
根据版本控制管理的方式不同，当前市场上的版本控制软件可划分为集中型版本控制软件和分布式版本控制软件。集中式版本控制软件以SVN为代表，分布式版本控制软件以Git为代表。
2.3.1 集中式版本控制软件
在集中式版本控制软件中，代码集中存储在某台服务器上。项目人员使用时，需要先安装客户端软件，连接到版本控制软件的服务器端，将代码检出到本地，修改后再从自己的计算机同步更新或上传到服务器，如下图所示：
集中式版本控制软件的特点是所有的版本数据都保存在服务器端，项目人员在本地计算机中仅保存着自己以前同步的版本。在不连接服务器端的情况下，项目人员就看不到服务器上的历史版本信息。如果项目人员想切换到某个版本，也无法操作。除此之外，集中式版本控制软件最大的风险是所有数据都保存在单一服务器上，如果服务器受到损害，则有版本丢失的风险。为此，需要定期做数据备份。当然，也正是这种集中式、单一的管理方式，其使用比较简单，尤其对新手来说，很容易上手。
2.3.2 分布式版本控制软件
相比于集中式版本控制软件，分布式版本控制软件的使用相对复杂。项目人员在初次使用时，必须在本地计算机上克隆(git clone)一个完整的Git仓库，再基于这个本地仓库进行检入检出操作。再将本地仓库与服务器端仓库进行数据同步，从而完成版本控制管理的目的。如下图所示。
分布式版本控制软件对文件的修改通常以快照的方式记录版本差异。当本地仓库完成克隆之后，除非同步数据到服务器端，其他的操作都是在本地执行，无需联网。这对于网络环境相对封闭的项目组来说，多人协同开发版本管理比较方便。在分布式版本控制软件，中央仓库所在的服务器或版本控制软件的服务器端充当交换媒介的作用，将项目组中不同人员的修改进行交换，由修订人员在本地仓库间进行互相复制。同时，每个人的本地仓库都保存一份完整的版本库。
2.3.3 总结
从上述的这些特点来看，分布式版本控制软件的管理过程比集中式版本控制软件要复杂，但好处较为明显。目前在大中型企业管理中，分布式版本控制软件的使用占比高于集中式版本控制软件，分布式版本控制软件更适用于大规模的多人协作开发。
2.4 常用版本控制软件介绍
为了帮助大家在搭建DevSecOps平台时，选择契合业务实际需求的版本控制软件，下面介绍下常见的版本控制软件，如下图所示：
三、编译构建系统
3.1 概述
编译构建是源代码转为可执行程序过程中必不可少的一个步骤，在传统的开发模型中，编译构建通常是开发人员在本地计算机自己编译后上传版本库；在持续集成流程中，编译构建动作通常是平台上的持续集成工具来自动化完成的。除了基本的代码编译构建外，还有容器镜像的构建。
3.2 编译构建流程示意图
当开发人员提交代码之后，触发持续集成平台中的编排调度系统发起调度流程执行编译构建动作。编译构建系统会根据不同的编程语言选择不同的编译工具将源码进行编译打包成制品。如果制品还需要制作成容器镜像，则继续调用镜像构建流程。
3.3 列举Java 源码编译构建流程
3.3.1 Java代码编译构建流程示意图
下面以Java语言的源代码为例，介绍代码编译构建过程，如下图所示：
当编译构建系统执行编译指令时，编译工具的编译引擎先解析编译配置文件，根据配置文件中的配置从中央仓库或本地缓存中获取版本所需要的依赖库，再对源代码进行编译，执行编译过程如果编译没有发生阻断性错误，则最终输出编译产物，即可执行程序或制品包。当有新的版本迭代时，重新触发上述流程，持续编译输出编译产物。
当代码编译构建完成打包成制品后，如果没有使用镜像，则流程结束；如果有镜像制作，则触发镜像构建流程，如下图所示：
在整个流程中，编排调度系统充当流程管理员的作用，通过不同的指令，将代码下载、依赖下载、应用制品打包、镜像制作的流程串联起来，形成持续集成管道化的功能。
3.4 持续集成产品架构分层
3.4.1 持续集成产品架构分层示意图
从这些流程可以看出，不同的开源产品在持续集成平台架构中分别承担不同的功能。如果将这些开源产品进行系统分层，则结果如下图所示：
上图中，持续集成工具即编排调度层充当持续集成流程的管理中枢，并直接面向最终用户；编译工具层提供各种不同的开发语言编译工具，承上启下，连接编排调度层和基础代码仓库；而基础数据层则为上层的编译构建操作提供原始的源代码及代码管理功能。
3.5 常见编译工具列举
因开发语言、运行环境的不同，编译工具也各不相同。常见的编译工具如下图所示：
四、编排调度系统
4.1 概述
介绍完编译构建系统，再来看看编排调度系统。编排调度系统充当了代码编译、构建镜像、通知推送几个步骤的综合管理和调度工具，这就是编排调度系统的核心使用场景。
4.2 编排调度系统示意图
如果把代码编译、构建镜像、通知推送看成3个独立的任务，编排调度系统是调度中心，这就是编排调度系统的核心能力构成：任务、编排、调度。
4.3 编排调度系统构成内容解析
4.3.1 任务
在前文提及持续集成流程时，我们了解到整个流程是一个个动作串联起来的，这一个个的动作可以当作一个个具体的执行任务。体系在平台中，则需要完成任务所支撑的代码片段，这些代码片段能完成具体功能，如代码提交、代码安全的自动化检查、单元测试用例的覆盖度检查等。这些，在平台中统一称之为任务。
4.3.2 编排
编排是指不同的任务之间，通过一定的排列组合、先后顺序的承接，来完成一个整体的作业流程。进行排列组合和组装顺序的过程称之为编排，编排后的整体流程称之为作业。例如，代码提交后，接着执行单元测试用例覆盖度的检查，再执行代码缺陷的自动化检查；也可以代码提交后，先执行代码安全的自动化检查，最后执行单元测试用例覆盖度的检查；还可以设置多次代码提交，但不触发代码安全的检查，只有当代码编译构建通过后，再触发代码安全的自动化检查，这个流程中，代码提交的任务被触发了多次。这也是编排的一种。总之，编排就是通过不同的组合方式，来完成任务执行顺序关系的设置，以满足业务的需要。
4.3.3 调度
调度是指在不同的任务执行过程中，需要分布跟踪、调度任务的执行及执行情况，以根据上一步执行结果调用不同的下一步任务的过程。例如，代码编译后执行代码缺陷检查任务，如果代码缺陷检查调用不成功，则切换编译环境，再次执行代码编译、代码缺陷检查任务。这个流程的控制称为调度。调度通常关注任务执行的结果，被调用方常常是跨子系统的。
4.4 编排调度软件举例
目前，常用的编排调度软件（即持续集成工具）如表所示：
在知道了常见的持续集成编排调度软件，了解了编排调度的基本概念之后，大家也基本明白为什么在DevSecOps平台中需要编排调度系统。如果没有编排调度系统，不同的流程无法统一用平台来管理，不同的任务无法在平台中进行统一配置，DevSecOps规范中设置的安全卡点也就无法在平台中完成线上业务的承载。
4.5 编排调度系统的核心功能
既然编排调度如此重要，那么编排调度系统中，到底包含哪些核心功能呢？
4.5.1 流程编排管理
流程编排管理是编排调度系统中的首要功能，每一个流程编排运行时产生一个流程实例，任务是此持续集成流程中最小的集成单元。对于整个流程来说，它是由一个一个的任务组合在一起形成的，为了完成这些不同任务的组合作业，在DevSecOps平台中，需要有任务编排管理的功能来形成流程。任务编排功能页面如下图所示：
如图所示，用户在编排时，可以在不同的阶段添加不同的任务。例如，在构建阶段添加对SCA的调用，检测开源组件安全漏洞；开发提测前，添加必须通过静态代码安全检测的任务等。当任务编排完成后即形成一个可以执行的具体作业，作业的完成依赖于其中每个任务的执行完成情况。一个标准的作业流程就是一次流水线管道的执行。在作业的实际执行过程中，不一定每一个任务都会执行到，有可能存在某个任务出现异常或被跳过的情况。如果某个任务中包含子任务或其他并行任务，则需要对子任务或并行任务进行配置管理，以保障作业流程的顺利执行，这也是任务编排管理的内容。
4.5.2 任务配置管理
在任务配置管理中，需要管理单个任务执行的基本参数，如开始条件、执行次数、调用脚本或脚本路径、相关参数配置等，这是任务配置管理的基本功能。除此之外，当某个任务执行存在多个入口或者多个出口时，也需要任务的路由策略进行配置管理。在某些企业，因任务的种类繁杂（如API接口类任务、bash脚本类任务、操作系统命令行类任务、数据操作类任务等），平台设计时会抽象出一个适配层去适配各种不同的任务执行环境，这也是任务配置管理的内容。典型的任务配置管理页面截图如下图所示：
对单个任务而言，一般都承担着流程中的某个具体的动作，如代码扫描、编译检查。除此之外，还有一些任务节点在整个流程不承担具体的动作，类似流程图上的开始、结束节点，但对于整个流程来说，这些节点也是不可或缺的。这类节点的任务配置也需要任务配置管理来实现，不同的是，这些任务配置可以标准化或模板化，以方便平台用户的使用。
4.5.3 作业调度管理
任务通过编排形成作业之后，进入作业调度管理。通过作业调度管理作业的启动、流转和结束。当多个作业同时执行时，需要管理不同作业之间的优先级，为优先级高的作业提高资源保障，这是调度管理的基本功能。很多时候，多个任务之间有着强依赖关系，如只有前置任务执行完成，才可以启动当前任务。这时对前置任务执行状态的监控和当前任务的拉起都离不开作业调度管理。同时，在作业流程的执行中，对任务节点的执行情况进行监控，当任务节点的状态发生变化时，及时跟进作业流程的状态。如果缺少了作业调度，则任务无法执行或执行混乱；如果作业流程缺少监控，则无法跟踪作业流程的执行状态，对于执行异常的任务也无法发现，及时干预和处置。基于任务监控功能之上的异常告警、任务重发、异常处理等都是作业调度系统中必不可少的功能模块。
4.5.4 历史日志管理
操作日志是每一个信息化系统必不可少的功能，在编排调度系统中，历史日志管理尤为重要。在前文中曾提及，编排调度的最小单元是一个个的任务，这些任务相互之间是独立的，通过流程串联、接口调用将它们联合在一起。这种跨模块、跨系统的调用，如果没有历史日志将是很糟糕的事。通过历史日志可以还原流程执行中任务的执行顺序、单个任务执行的过程详情、异常故障的原因分析、历史流程的归纳统计等。
五、其他系统
5.1 概述
除了上述三个系统外，在持续集成流程中还有一些其他的周边系统参与整个流程的协作中，典型的如企业配置管理数据库(CMDB)、资源管理系统、制品仓库等。
5.2 企业配置管理数据库(CMDB)
CMDB主要是对企业IT资产的信息及这些资产的配置信息管理，通常是运维管理系统、资源管理系统的基础，为运维管理、流程管理提供基础数据。使用CMDB可以帮助DevSecOps平台解决应用与应用、应用与技术组件、应用与基础设施的关联关系，如下图所示（CMDB中资产映射关系示意图）。
5.3 资源管理系统
资源管理系统主要是对IT资源进行综合管理，如资源申请、资源分配、资源占用、资源回收等。资产可API化管理和CMDB数据的及时准确是自动化运维的基础。尤其是在大量服务运行的IDC环境或云原生环境下，通过资源管理系统，一方面可以实现对资源的精细化管理，提高资源使用效率，降低IT成本；另一方面，为资源的合理使用及资源之上服务运行的稳定提供基础保障。云计算环境下的资源管理系统产品功能如下图所示：
5.4 制品仓库
制品仓库主要与软件研发过程相关，用于存储软件交付的成果性产物。例如，可发布的二进制安装包、可执行应用程序；编译构建阶段的阶段性输出产物等。
5.5 总结
这些相关系统的存在为整个研发过程中的持续集成、持续部署、线上运维等流程提供基础的平台保障，也是DevSecOps体系中不可或缺的一部分。
好了，本次内容就分享到这，欢迎大家关注《DevSecOps》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
