Web持续集成工作实践

492 阅读8分钟


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

摘要

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

嘉宾演讲视频及PPT地址:t.cn/RN2d4Eb

背景

在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);。

手动构建

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

总结


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

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

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

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

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

我今天的分享就到这里,感谢聆听!