内容来源：2017年3月11日，下划线技术总监王集鹄在“HTML5梦工场 & 微软开发者沙龙第02期——HTML5营销开发”进行《Web持续集成工作实践》演讲分享。IT大咖说（ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：2395 | 5分钟阅读

嘉宾演讲视频及PPT回顾，请点击链接：http://t.cn/RdTSv7M

摘要

如果团队开发成员经常集成他们的工作，每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建来验证，从而尽快地发现集成错误。那么这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

背景

在2015年10月我加入了一家创业公司。创业公司的工作方法就像打开冰箱门做一顿饭，看到冰箱里有什么就做什么，更不要说什么持续集成了。

当创业公司不断壮大，就会出现各样的问题。持续集成是通过平台串联各个开发环节，实现和沉淀工作自动化的方法。持续集成是一个持续的过程，不能一步到位。它是不断完善、不断迭代去修复问题，当新的需求或问题出现的时候再去满足它。自动化就是能交给机器的都交给机器去做。

为什么要做持续集成

线上代码和代码仓库不同步。加盟公司后，我发现上线部署是通过FTP直接上传代码，使用文件比较工具进行代码合并。由于配置不一样，修改的人不一样，经常导致代码仓库和线上代码不统一。每次上线之前代码都要做一次线上线下手工合并。

缺少自动化测试。每次上线仅仅依赖人工测试，测试用例难以覆盖所有被影响的功能，常常出现初级的接口问题，直到产品上线用户反馈后才能发现问题。

只有程序员才能上线。活动页面的文案需要运营同学反复推敲，频繁修改习以为常。可每次修改文案都需要研发同学介入才能部署生效。为修改一个字，研发就需要陪运营熬到很晚。

自动化的需求

自动编译：自动引入各种依赖（开发依赖、包依赖、配置依赖）。资源自动转码、合并、压缩。自动处理配置文件。

自动部署：静态资源自动上传CDN服务器。应用文件自动上传和同步到应用服务器。

自动测试：自动进行单元测试、集成环境测试。

自动监控：构建异常、测试异常、运行异常自动通知相关负责人。

团队协作的需求

成员快速体验最新版本。第一时间部署内测版本，并自动通知团队成员。

策划直接修改文案上线。面向用户的说明文档，如仅文案修改不需要介入研发人力，即可完成线上更新。

设计师直接更新素材。设计师可以直接更新图片资源，图片自动切割、转码、上线。

数值工程师直接更新配表。数值工程师指游戏场景中的设计装备、属性和等级数值关系的人。数值配置通常是一份Excel文件。需要自动编译、更新和推演。

适配各种运行环境

本机环境local：应用能最少依赖在本机运行。能够及时修改和预览代码。能够模拟运行环境（接口或数据）。

开发环境develop：一般Web项目上线前，都会有一个局域网的开发环境供团队成员测试和体验。开发环境有完整的沙盒数据与线上隔离。方便打印完整日志、提供特权。

线上环境online：线上环境也叫生产环境，直接面向用户。访问的是真实数据，测试和体验时需非常谨慎。通常会上线多个版本，方便测试和回滚。

敏捷开发的需求

时间上要小步快跑，推进每次迭代速度，沉淀工作方法。

空间上要将各个岗位的工作汇集和串联实现自动化。

怎么做持续集成

CI需要的工具

统一的代码仓库GitLab；

构建平台Jenkins、Travis CI；

构建工具Gulp、FIS3；

部署工具rsync。

创建CI项目

进行基础设置，指定代码仓库和相关授权用户，设置构建触发器，设置构建脚本，设置构建异常通知。

构建实例

简单文案更新由运营同学完成。运营同学不需要安装其它软件，直接在浏览器中修改GitLab项目文件（通常是HTML中的文案），保存即刻更新上线。

数值工程师配表。数值工程师通过修改Excel文件，更新数值配置。

设计师发布CDN资源。在GitLab中可直接拖拽文件上传。转码、部署自动完成。

集群服务自动部署和测试。高并发的Web应用，通常都有很多分片（可以理解为多个主机）。代码需要同步到各个分片上，而各个分片可能有微小差异，不一定每次代码迭代全都能正常运行。我们将每一个分片提出一个测试端口，上线前各个分片均做一次测试用例覆盖，确保集成服务的稳定性。

使用成本

学习和使用成本

持续集成几乎覆盖了开发环节和运行环境方方面面，普通项目组成员不一定都能接触。所以我给组内的同学下放更多的内网环境权限。当然我们也可以自行安装相关环境。

线上环境隐私保护

线上环境的操作需要十分谨慎，一些配置有很高的保密性。包括但不限于第三方支付授权码、第三方应用授权码、文件部署授权码、数据库用户身份，也就是各种重要的私密配置。

区分不同运行环境

本机运行、开发环境（个人开发环境、稳定版、开发版）、线上环境（预上线、灰度上线），都需要通过配置或环境变量区分。

构建过程自身异常

就构建本身也可能出现异常。例如构建机器软硬件异常（网络中断、磁盘满了、编译依赖升级失败），还有节假日不在办公环境。

错误覆盖线上项目的风险

克隆构建任务也是有风险的，因为有相同的部署配置，处理不好会覆盖之前的线上代码，导致线上事故。

实践经验

项目规范

无论是前端项目还是后端项目（PHP、NodeJS、Go），我们都用package.json来定义。方便统一项目名称、版本、构建脚本的来源。

构建过程使用跨平台的脚本

可以选用PHP、NodeJS、Python等跨平台的脚本，方便运行到各种环境中。不建议使用VBScript或JScript，仅能在Windows直接运行的脚本。

编写小成本测试用例

编写测试用例也不一定要引入重型的测试框架，其实只要进程以非零状态退出就可以中断构建过程。NodeJS用process.exit(1);，PHP用exit(1);。

手动构建

为避免开发期成员部署项目互相干扰，给每个成员分配了一个独立端口。代码不需要提交到仓库，通过手动部署相应项目。

总结

上图是不同的开发过程。从需求阶段，到开发、测试、上线，再到运维，信息层贯穿了整个工作流。

产品和研发会变更项目成员、项目文档或一些基本信息，做一个项目管理。

研发和设计师会不断地更新素材、文案和代码以及开发文档，所有东西都会进入代码仓库。

每次代码变更都会通知构建平台，构建平台从代码仓库中拉取代码和配置进行构建。构建完成后就把构建好的文件部署到各个环境中去。

测试完就可以发布了，上线后进行同步，最后进行自动化测试。这就是整个上线流程。

我今天的分享就到这里，感谢聆听！