前言
这几天天气突然降温，你们可要注意身体春天容易感冒。2月25号周末，今日早读文章来自@王集鹄大叔的授权分享。
正文从这开始~
背景
2015年10月我加入一家已盈利的创业公司持续集成，负责 Web 技术方向。
创业过程中为了生存持续集成，都是拼快拼狠，难免选用猛糙快的工作方法。
随着业务和团队不断扩大，面对的问题也越来越具挑战性。
我逐步将一些自动化工具和方法引入到日常工作中，使团队获得一些收益。
什么是持续集成（ ）？
个人理解：持续集成是通过平台串联各个开发环节，实现和沉淀工作自动化的方法。
持续集成在敏捷开发中运用得非常广泛，几乎成了各种项目的标配。
我认为持续集成是研发团队负责人必须了解和掌握的方法。
我们为什么要做持续集成
引入各种方法都是为了解决各种问题。
引入持续集成之前碰到的问题
加盟公司后，我发现上线部署是通过 FTP 直接上传代码，使用文件比较工具进行代码合并。由于配置不一样，修改的人不一样，经常导致代码仓库和线上代码不统一。每次上线之前代码都要做一次线上线下手工合并。
图片资源转码、压缩、部署都需要人工介入。静态资源的 CDN 链接也需要人工替换。
每次上线仅仅依赖人工测试，测试用例难以覆盖所有被影响的功能，常常出现初级的接口问题，直到产品上线用户反馈后才能发现问题。
重运营的产品，节假日均有运营活动。活动页面的文案需要运营同学反复推敲，频繁修改习以为常。可每次修改文案都需要研发同学介入才能部署生效。为修改一个字，研发就需要陪运营熬到很晚。
持续集成的需求
为了解决上述这些问题，我们迫切需要改变一下工作方法，梳理需求如下。
自动化
不想把任务丢给机器执行的程序员不是好程序员！（当然用机器抢月饼除外）
自动引入各种依赖（开发依赖、包依赖、配置依赖）。资源自动转码、合并、压缩。自动处理配置文件。
静态资源自动上传 CDN 服务器。应用文件自动上传和同步到应用服务器。
自动进行单元测试、集成环境测试。
构建异常、测试异常、运行异常自动通知相关负责人。
团队协作
持续集成也不仅是研发岗位需要， 测试、产品经理、设计师、运维等岗位一样需要。
设计师可以直接更新图片资源，图片自动切割、转码、上线
第一时间部署内测版本，并自动通知团队成员
面向用户的说明文档，如仅文案修改不需要介入研发人力，即可完成线上更新。
数值工程师指游戏场景中设计装备、属性和等级数值关系的人。数值配置通常是一份 Excel 文件。需要自动编译、更新和推演。
适配各种运行环境
应用能最少依赖在本机运行。能够及时修改和预览代码。能够模拟运行环境（接口或数据）。模拟 Ajax，推荐使用 Mock.js
一般 Web 项目上线前，都会有一个局域网的开发环境供团队成员测试和体验。开发环境有完整的沙盒数据与线上隔离。方便打印完整日志、提供特权供。
线上环境也叫生产环境，直接面向用户。真实的业务数据，测试和体验时需非常谨慎。通常会上线多个版本，方便测试和回滚。
敏捷开发
怎么做持续集成
需要的工具
工欲善其事必先利其器。如今持续集成被应用得如此广泛，必然有很多成熟的工具可以选用。
强烈推荐 ，类似一个私有 。代码仓库、里程碑、成员、静态资源、文档、持续集成、静态网站等等，几乎覆盖软件开发需要的各项功能。
我们使用的是老牌持续集成平台 ，当然也有很多后起之秀比如 CI。
Web 构建工具也是百花齐放。我们选用的是 FIS3 和 Gulp。主要是除了前端以外，我们还要处理 PHP、、Go 等运行环境。
由于多数情况使用的是 FIS 发布，所以自己扩展了 FIS 部署接收器。但从性能、安全性上推荐 rsync 老牌的同步工具。
为兼顾团队成员同时使用 和 Mac 开发，测试、编译环节尽量使用 、PHP 这类跨平台的脚本。持续集成我们选用 Shell 以便跨语言使用。各种工具需要的运行环境就不一一赘述。
工具都在不断演进，需根据自身团队情况自行挑选。
持续集成工作示意图
创建 CI 项目
如果使用 + 组合参考： Hook
项目名称、描述、任务类型等等
指定代码仓库访问链接、有权限拉取相关代码的授权用户
指定触发类型同时在代码仓库平台（如：）添加触发构建请求的时机和地址。
设置构建脚本，建议使用 Shell
根据自身项目特点，我们约定了几个常用的 NPM
指定构建负责人的邮件，当发生构建发生异常和修复时通知负责人。
收益
陆陆续续对持续集成的探索和实施，确实有一些显而易见的收益
重复繁琐的工作可以自动化。团队工作流程可以不断完善和沉淀。
部署前测试、部署后测试，测试用例覆盖各个基本功能。测试发现和用户反馈 Bug 可以转为用例，持续加强测试覆盖率。
通过构建过程自动配置各种运行环境，整个开发过程均只维护一套代码仓库。
每次代码文档变更均产出可体验的版本，加速测试和体验产品介入的时间。
构建实例
举几个实际的例子
网页游戏素材资源自动上线
换装类游戏，经常会添置服装饰品。设计师提供 png 素材，有构建工具自动转成 webp 资源发布到 CDN。
日常活动文案更新交给运营
将运营的同学加到 项目成员。运营同学不需要安装其他软件，直接在浏览器中修改 项目文件（通常是 HTML 中的文案），保存即刻更新上线。
集群服务自动部署和测试
高并发的 Web 应用，通常都有很多分片（可以理解为多个主机）。代码需要同步到各个分片上，而各个分片可能有微小差异，不一定每次代码迭代全都能正常运行。我们将每一个分片提出一个测试端口，上线前各个分片均做一次测试用例覆盖，确保集成服务的稳定性。
使用成本
解决老问题的同时也会带来新的问题。
持续集成几乎覆盖了开发环节和运行环境方方面面，普通项目组成员不一定都能接触。所以我给组内的同学下放更多的内网环境权限。当然也可以自行安装相关环境。
线上环境的操作需要十分谨慎，一些配置有很高的保密性。包括不限于：第三方支付授权码、第三方应用授权码、文件部署授权码、数据库用户身份，即：各种重要的私密配置。
我们的做法是准备另一套代码仓库专门管理线上配置，仅对管理员开放。
本机运行、开发环境（个人开发环境、稳定版、开发版）、线上环境（预上线、灰度上线），都需要通过配置或环境变量区分。
就构建本身也可能出现异常。如：构建机器软硬件异常（网络中断、磁盘满了、编译依赖升级失败）。还有节假日不在办公环境。
需要准备短时手工介入维护的方案，比如：预留个系统升级页面，可以争取时间，不容易降低体验。
有时为敢项目进度，通常使用程序员必杀技 Ctrl+C、Ctrl+V。克隆构建任务也是有风险的，处理不好会覆盖之前的线上代码，导致线上事故。
为避免这种问题出现，我们在构建前加了一段代码以核对构建项目名称
实践经验
无论是前端项目还是后端项目（PHP、、Go），我们均用 .json 来定义。方便统一项目名称、版本、构建脚本的来源。
可以选用 PHP、、 等跨平台的脚本，方便运行到各种环境中。不建设使用 或 ，仅能在 直接运行的脚本。
编写测试用例也不一定要引入重型的测试框架，其实只要进程以非零状态退出就可以中断构建过程。 用 .exit(1);，PHP 用 exit(1);
没有规矩不成方圆，使用统一的规范可以更好的进行团队协作。
比如：用 .json 声明项目、用 NPM 写构建入口脚本、用 字段核对构建项目。
为避免开发期成员部署项目互相干扰，特给每个成员分配一个性端口。代码不需要提交到仓库，通过手动部署相应项目。
最后安利一下： -- 强大的代码块预处理工具，轻松适配各种运行环境。
参考
最后，早读君为你推荐：
关于本文