顾利军，邱敏明

（上海海事大学信息工程学院，上海 201804）

0 引言

在现代软件开发过程中，很多的软件项目都是由不同的开发人员负责，每个开发成员负责不同的功能模块，在项目开发结束之前，每个开发人员只关心自己的工作，却不了解项目的整体情况，自己开发的模块可以单独的运行工作，到最后项目集成为最终产品的时候，会产生一些意料不到的问题，有的很难去修复，有的不得不去重写几周或者几个月之前写的代码，甚至有的开发人员开发的模块会被全部否定而从零开始，最严重的情况将导致整个项目的失败。把项目的集成放到开发周期的最后阶段，将会花费大量的时间去进行集成工作，严重的bug处理会涉及到很多分支，给开发人员的修复工作也带来了很多麻烦，同时也充满了风险和危险，并且往往会导致延迟交付，造成额外开销的后果，引起客户的不满。为了解决这样的问题，人们进行了很多的探索，提出了“早集成，常集成”的集成策略，从最开始的分阶段构建，到之后发展的日构建，再到目前的持续集成（Continuous Integration，CI），持续集成的开发方式从简单的形式上讲就是一个能够监控版本控制系统变化的工具，只要检测到程序有新的变更的时候，这个工具就会执行一次构建，自动编译和测试你的程序，并且可以随时打包成可以交付的产品。如果在构建的过程中出现了问题，就会马上通知开发人员，开发人员就会停下目前的开发工作，着手去解决构建过程中出现的问题，防止到项目后期出现难以修复的难题，这样的持续集成可以保证软件在开发的过程中始终处于一个“健康”的状态。持续集成是一些基本的实践。它不是软件开发中最耀眼的工作，但持续集成对于如今的复杂项目来说是至关重要的，甚至项目负责人会把CI看成是软件开发的中心工作，因为它通过每次代码的变更执行构建，构建的过程保证了软件的健康。

本文基于日常多项目的实践开发管理经验，持续集成理论的研究以及对目前常见的持续集成工具的实践探索，提出了一套基于Git的持续集成方案，搭建自己的CI系统，从而解决项目开发中的集成难题、增强项目的可见性。

1 持续集成的理论研究

1.1 持续集成的概念以及研究价值

持续集成的概念最早出现在极限编程作者Martin Fowler的一篇文章《持续集成》中，持续集成是一种软件开发实践，即开发人员需要经常性地对他们的工作进行集成，每个开发人员每天至少进行一次集成工作，这样每天就会发生很多次的集成。每次集成过程都会执行并且执行相关的自动测试，这样就能及时地发现软件中存在的问题。

持续集成的价值很高，一个完善的持续集成系统能够减少项目风险，一天进行多次集成，有利于检查项目缺陷，及时的修复可以保证软件的健康；能够减少项目活动中代码编译、测试、打包、部署的重复工程，每次构建都执行相同的过程，减少重复劳动；能够保证项目在任何时间都可以发布可部署的软件，每次小的代码改动都会及时地与项目中其他的代码进行集成，及时发现问题及时修复，不采用CI的软件开发项目可能会等到最后交付的时候才会进行集成及测试，可能会出现不可修复的缺陷，导致延迟发布或项目失败；能够增强项目的可见性，持续集成使得项目能够随时保证最新的数据来进行决策，而没有CI的项目通常需要开发人员手动收集信息，增加了工作负担浪费了很多宝贵的时间，使得项目进程缓慢；最后持续集成还可以在团队中建立强大的产品信心，因为每一次构建的结果都能让开发人员对项目的整体结构做到心里有数，如果没有持续集成，开发人员就不知道修改后的代码会不会对整个项目造成影响，CI的及时构建结果及时通知，让开发人员在开发的过程中更有信心开发出有品质有保障的软件产品。

1.2 现有集成工具的分析

目前软件行业中使用较多的持续集成工具是Jenkins，Jenkins最开始被称Hudson，是一个用Java语言编写的开源的持续集成工具，被应用于各种规模的团队用于各种语言和技术的项目中，例如Java、PHP、C#等，而且Jenkins有着丰富的开源插件库，使得Jenkins的构建功能比较健全。但是Jenkins也有很多不足的地方，首先是界面非常的不友好，页面的有些部分要靠插件生成，使用不够方便，经常会让人对插件的使用非常困惑，不知道其对应的页面部分在什么地方，这也许就是Jenkins当初在开发的时候所采用了Jelly页面技术所带来的局限性吧，同时插件也没有中文解释，只有部分英文资料，对于国内的开发者来说使用有些困难，若从更深的角度讲，在扩展Jenkins的时候尽可能的使用插件会是更好的选择，可是插件越多Jenkins的性能损耗就越大，这也是Jenkins陷入了难以走出的循环泥潭，开发者需要选择性能还是选择扩展的风险。另外Jenkins的build流程不够清晰，甚至国内有些软件公司自己重写了持续集成的管理页面来调度Jenkins的build计划，这已经足够说明了使用流程不够清晰这一点。

基于Jenkins的页面不够友好，插件使用不够灵活方便，插件的增多带来性能上的损耗以及构建流程不够清晰等这些缺陷，我们将开始设计自己的CI系统方案，最终实现方便使用灵活配置且能够满足日常构建的持续构建系统。

2 持续构建系统的方案设计与实现

2.1 持续构建系统的组成部分及构建流程

图1 持续构建系统的组成部分以及构建流程

持续集成系统的基本要素有开发人员、Git版本控制系统、持续集成构建系统、多语言构建工具以及构建结果的反馈组成，这些组成部分之间相互配合共同完成从版本变化到自动构建，再到构建结果的反馈，从而形成完整的构建过程。持续集成的应用场景开始于开发人员向版本控制库提交变更代码，由版本控制库Git的Hook脚本向持续集成系统发出变更通知，然后持续集成系统从Git版本库中检出项目代码的最新版本，继而触发持续集成系统进行构建。图1展示了持续集成系统的基本组成部分和构建流程。

2.2 持续构建系统的方案设计

基于持续集成的基本理论以及多种语言项目的探究与实践，提出了以下的持续构建系统的设计方案，如图2所示。

持续集成构建系统中，我们选择Git作为版本控制系统，Git是近年来最流行的软件之一，它的去中心化架构以及源码变更交换的速度被很多开发者青睐。在Git的众多优点中，最有用的一点莫过于它的灵活性。通过“hooks”（钩子）系统，开发者可以指定Git在不同事件、不同动作下执行特定的脚本。该系统中主要利用了Git中的钩子系统，当开发者向Git仓库提交变更的代码的时候，触发Git的hooks系统，执行钩子脚本，继而引发该项目进行构建。

图2 持续集成构建系统

如果是第一次进行构建时，要执行创建构建项目，进入到构建配置页面，进行项目配置，包括项目名称、项目类型、构建工具、是否清掉旧的构建历史、是否测试、是否部署等等配置选项。构建配置好后点击保存，数据提交到后台后将会被序列化保存到xml文件中。一切工作准备好以后，点击构建，持续集成系统就会立刻执行构建流程，最后将构建的结果显示到集成构建系统的Web页面上，同时本地服务器也会保存构建项目的最近一次的构建结果，这样每个开发人员都可以查看集成构建的信息。

2.3 持续构建系统中的关键技术与实现

（1）构建项目配置中项目类型的自动检出

传统的CI服务器中构建项目的配置页面无法检测出项目类型，都需要手动配置，而且在配置的时候都不清楚本地环境中是否支持该种类型项目的构建，即本地是否安装了相应的构建工具。我们设计的持续构建系统在设计之初就对现有的构建工具做了大量的调研，将目前软件行业常用的构建工具进行了分析，发现不同的构建工具都有不同的构建配置文件，这些配置文件都有固定的命名规则或后缀名，根据命名或后缀名，我们就可以判断该项目是有哪种构建工具构建的。如果本地环境中没有安装构建工具，系统也会有相应的提醒功能。图3展示了项目类型自动检出的简单流程。

图3 项目类型自动检测

（2）调用构建工具执行构建

构建工具都是通过执行shell命令执行相应的构建操作，该系统是基于Java语言开发的，因此我们调查研究了如何在Java环境里执行shell命令，发现Java API中封装了一个Runtime的类，该类封装了操作系统的运行时的环境，每个Java程序都有一个Runtime类实例，使应用程序能够与其运行的环境相连接，其API中有一个方法exec(String command)，该方法能够在单独的进程中执行指定的字符串命令。我们通过读取构建配置里的配置参数将其转换成相应构建工具中的构建命令，后台程序中将路径信息path与构建命令拼接作为参数，将其传入到exec方法，即可执行构建过程，如String command=path+"mvn compile";Runtime.get-Runtime().exec(command);便可完成对MAVEN类型的项目进行编译构建，构建的结果会返回到Web页面进行展示，同时也会将构建结果序列化到本地进行保存，保证其他人都可以查看集成构建信息。

（3）本地部署与远程部署

由于不同语言的项目部署情况也不同，而且部署在自动构建部分属于可选部分，目前我们在配置页面提供了一个Execute shell的输入文本框，支持编写自动部署的脚本，待构建完成后执行自动部署的操作，如果输入内容为空，默认不执行部署。

3 系统构建结果展示

持续构建系统采用Java Web开发技术，整体架构为JSP+Bootstrap+Spring MVC+Spring技术，运行服务器为Tomcat。首先点击创建一个构建项目，设置项目构建任务名称，配置参数等，然后点击保存、构建，以Maven搭建的一个Web项目为例，构建结果如图4所示。

图4 Maven类型项目的构建结果

最后，构建的结果是BUILD SUCCESS,实现预期的构建效果。

4 结语

本文对持续集成的理论进行了研究，分析了持续集成的基本组成部分及构建流程，并对目前流行的持续集成工具Jenkins进行了介绍，分析了不足的地方，在此研究学习的基础之上，提出了基于Git的持续集成方案，设计并开发了集成构建系统，该系统集成了前端模块化打包方案webpack，并集成了多种语言的打包工具，能够支持前后端打包一体化以及多语言项目的构建，省去了Jenkins繁琐的插件配置，优化了构建流程。此系统的设计开发由于时间有限，并考虑到自动化测试复杂性，以及不同语言项目的部署也没有统一的标准，我们提出的持续集成方案在这两个方面没有做太多的研究，提供了支持编写部署脚本来进行部署，后续会对不同语言项目的部署进行分类设计不同的部署方案来代替部署脚本。