前端持续集成技术的研究与应用

黄 嵩，丰大军，胡 戎

(华北计算机系统工程研究所，北京 100083)

0 引言

近年来，由于软件行业的迅猛发展，软件变得越来越复杂，单靠个人根本无法完成中大型的项目开发。而中大型软件为了解耦，往往还需要分成好几个模块，各个模块既需要各自独立的功能，也需要合并成一个整体应用，这样集成就成了软件开发中不可或缺的一部分。持续集成(Continuous Integration，CI)就是让开发人员经常整合各自的工作结果，这个频率可以自己决定，但是通常是一天一次，以免影响成员的正常开发。每一次集成都会完成一次自动构建，用以尽早地发现开发过程中的错误[1-2]。

术语持续集成来源于极限编程，它是极限编程的12个基本原则之一。在开发实践中，经常进行项目的集成工作有利于使项目保持良好状态，增强开发人员的信心，因此集成工具应该继续推行[3-4]。

同时，随着前端新技术的不断推行，持续集成已经不再是仅限于后端开发过程。现代前端开发中的前后端分离、工程化、自动化等开发模式正在变得越来越流行，前端项目还引入了现代软件工程化的标准环节，包括编译、构建和单元测试等，大大提高了前端的开发效率和业务交付能力[5-6]。作为前端工程化中的一环，持续集成也渐渐开始在前端项目中使用。

本文抛弃传统的前端开发部署方式，使用持续集成工具Jenkins、构建工具Webpack以及Docker容器等工具完成了一个前端持续集成系统的自动化流水线。

1 传统软件开发

以传统的瀑布开发模型为例，一般情况下将软件开发过程分为设计阶段(包括需求分析、概要设计、详细设计)、开发阶段(代码编写)、测试阶段(单元测试、端到端测试、功能测试)和运维阶段。瀑布开发流程图如图1所示，在瀑布模型中，项目开发的早期阶段是无法检测到无论是需求还是设计中的问题的，这样会导致开发人员一次次地重复进行上述四个阶段，使得项目不断地推迟交付，甚至最后无法完成。而且，这些问题只是一部分，最重要的问题是每一步都需要不同的开发人员手动执行[7]，导致整个开发流程过于冗长，开发周期很难理想控制。

图1 瀑布开发流程图

其他软件开发模型包括螺旋模型、喷泉模型甚至智能模型等近现代的开发模型虽然对这种原始的瀑布模型做出了各种角度的优化，但都只能一定程度解决某个过程的问题，整个开发过程依旧步骤繁多，开发、测试、运维人员需要依次手动执行流程，不能满足现代软件开发对敏捷化、智能化、自动化的需求[8]。

2 持续集成系统

2.1 系统结构

CI是一个持续提交、不断构建的过程。当以团队形式开发产品时，首先成员需要各自开发自己分配到的模块，在完成各自的工作后，需要将这些代码集成到统一的代码库，这里使用的代码库是Gitlab代码库。代码提交后，需要通过使用CI工具Jenkins，配合构建工具Webpack一起作为自动化构建工作的核心。

当代码库的代码发生更改，CI服务器被触发，服务器会自动下载代码库的新代码，并配合构建工具在约定好的工程目录下执行自动化的代码打包。这个过程中只要出现任何问题，CI工具都会通过电子邮件等方式通知订阅CI服务器状况的相关人员。

基于以上分析，并结合本项目选用的工具，图2给出持续集成系统结构。

图2 系统结构

2.2 系统组成

持续集成系统一般需要包含版本库、构建工具、持续集成平台等，该系统由以下几个模块组成：

(1)具有版本控制功能的代码库

版本控制代码仓库是持续集成系统的基础，现在通用的代码库包括SVN、Gitlab等,本文选用Gitlab作为代码库。

(2)构建工具

在持续集成的过程中，构建工具的作用是将那些需要手动执行的操作全部变成自动化操作。只要源码变动，构建工具就能自动将Gitlab库中的源码编译，并打包成可交付的代码。本文选用Webpack作为构建工具。

(3)持续集成平台

持续集成平台的作用是对整个持续集成流程进行管理，并实现流程的自动化以及产出结果的可视化。Jenkins是目前受众最多的持续集成平台，拥有相当丰富的插件，方便满足用户的各种需求，是持续集成和持续交付的核心。本文采用Jenkins作为持续集成平台。

(4)Docker

Docker是一个应用容器引擎，可以为应用打造一个轻量级、可移植的容器[9-10]，包括镜像、仓库、容器等核心概念。集成工具与构建工具打包出来的镜像文件最终需要推送到Docker的镜像仓库中。

(5)前端包管理工具

前端开发者在项目构建时经常会遇到项目配置文件中的依赖包问题，有了包管理工具就可以解决依赖包的各种问题，让开发者只需要关心自己的业务代码。本项目选用yarn和npm这两个前端最通用的管理包作为包管理工具。

3 系统流程

本系统是一个以Jenkins为核心配合构建工具生成镜像，并推送到Docker镜像仓库中的保存持续集成系统。持续集成的完整流水线包括4个步骤：检出代码、构建代码、镜像构建以及发布仓库，流水线如图3所示。

图3 流水线

3.1 检出代码

当开发人员完成自己的开发工作后，需要提交代码到约定好的Gitlab代码库，但是在提交之前，至少需要在本地进行一次单元测试，完成本地的测试后，才能将本地的新代码提交到Gitlab代码库，完成代码的检出。

3.2 构建代码

构建代码是持续集成的核心，构建代码的过程其实是Jenkins配合构建工具Webpack的打包过程，当开发人员将代码提交到Gitlab代码库，Jenkins平台检测到Gitlab库变化，此时调用Gitlab插件，从Gitlab库上下载开发者最新提交的代码，下载完成后通过包管理工具yarn下载项目配置文件package.json中规定项目所需的依赖包，然后调用Webpack插件通过build构建操作对新代码进行打包,并集成到指定的镜像地址。

Webpack打包的具体流程由Webpack的配置文件webpack.config.js决定，该文件配置了入口(entry)、出口(output)、loader转换工具以及插件(plugins)，出口文件即Webpack打包出来的文件。打包完成后只需要将出口设定的output文件上传到服务器即可，不需要上传整个项目文件。Webpack完成打包后，生成的dist文件就是用于构建镜像的打包文件。

如图4所示，在本项目执行构建代码时首先给出镜像仓库的地址，表示使用该镜像地址来作为dist文件的运行环境。进行编译时，首先配置npm淘宝源，设定镜像的环境变量，然后用yarn指令安装项目所需的所有依赖包，并进行build构建将整个项目打包生成dist文件，最终选定node:9-alpine环境下的dist作为镜像构建的基础镜像。

图4 构建代码

3.3 镜像构建

将代码构建成基础镜像后，需要通过配置Dockerfile文件将基础镜像产出为一个可移植使用的完整镜像。

如图5所示，本项目中Dockerfile执行了如下操作：

(1)FROM命令是Dockerfile的第一个命令,它的参数是一个镜像地址，表示使用该镜像地址下的基础镜像来启动构建镜像的流程。本环节的基础镜像就是上一步存放到node:9-alpine环境中的dist文件，二者一起构成基础镜像。

(2)RUN命令是Dockerfile执行命令的核心部分，显而易见，其功能就是运行其参数的shell命令，这里表示新建级联目录/usr/src/app。

(3)WORKDIR命令用于设置运行目录，在执行RUN参数的shell命令前会先进入WORKDIR后面的目录，这一步选定usr/src/app作为运行目录。

(4)COPY命令用于复制文件，COPY./usr/src/app表示将本地文件从该目录复制到镜像中。

(5)ENTRYPOINT是容器启动时的执行指令，由图5可知，容器启动时，执行了deploy操作，参照项目配置文件package.json可见：deploy:node build/scripts/start.js，即执行打包后的启动文件，完成镜像构建，镜像名称为baseinfo。

图5 镜像构建

3.4 发布仓库

最后将Dockerfile构建的镜像baseinfo发布到Docker的仓库，在使用时，可以直接用该Docker镜像创建Docker容器，如图6所示。至此完成构建前端持续集成系统的所有流水线。

图6 镜像发布

4 成果检验

在构建完全部流水线流程后，运行完整的持续集成流程来检验成果。如图7所示的新版本状态，从开发人员在Gitlab库提交代码到发布新版本成功只需要短短3 min，大大简化了传统的开发、部署、维护这些繁琐的过程，提高了项目版本发布的效率。

图7 版本状态

5 结束语

持续集成技术发展势头迅猛，其作用包括使开发者能避免重复操作，让流程自动化，降低开发风险，保持随时部署以及简化发布流程等，对于前端开发者而言，持续集成可以作为前端工程化、自动化、敏捷化的重要战力，为前端开发的流程优化提供了新的思路。