2014年底，我入职一家创业公司，主要负责web方向团队。

需要说明的是，这是一家节奏超快，风格强悍的公司。怎么说呢，就是说今天想出来的点子明天就想，哦不，不只是想！就是明天一定要上线验证的风格。

这种超快的节奏下,与之配套的前端工程化配置却是非常匮乏，于是我们便走上了一段工程化的心路历程。

先来看看我们当时面临的状况：

产品节奏非常快，明天就要上线（这个刚才已经说过）
前端只分为pc,mobile两个大工程，这两个平台的所有页面都在这里，耦合严重
构建，部署测试环境和线上环境基本靠手工。

再看看我们开发测试上线的流程：

1.前端项目全部通过ajax来和后端隔离，所以开发环境完全本地化，本地联调完，部署测试环境进行测试。

2.运维同学很慷慨的提供了非常多套测试环境（test1~test100），为了安全，测试环境和开发机之间有跳板机（堡垒机）隔离。

3.部署测试的时候通过grunt test1~tes100 生产测试包（2个包，一个页面包，一个静态资源包），copy到堡垒机，再copy到目标test环境相应目录（也是2个目录）。正式环境则grunt product出正式包，然后copy到跳板机，再copy到op指定机器的指定目录。然后有op(运维同学)操作上线。

以上状况带来了我们在日程开发工作上造成很大的困扰，很多时间被浪费在了部署上：

1.代码耦合严重，多人维护统一工程加上超快的开发迭代节奏，最后上线的事情只能是刀耕火种，即工程并非能全量上线，每次上线只能手工挑出来本次上线哪些文件

2.部署完全手工，先copy到跳板机，再到目标机器。重复体力劳动繁重。加上测试环境多，部署起来更是痛苦。

3.多人维护的项目经常会将不该提交的代码提交或者由于本地构建忘记update而导致上线出问题

4.测试环境测试过程中经常被覆盖，导致测试时间浪费

为了解决这种问题，我们分几步做了以下优化,最终形成了我们的部署系统ideploy.

第一步：用部署命令代替手工scp,减少重复体力劳动，告别刀耕火种

上面我们说过，一开始的构建部署我们完全在一种刀耕火种的方式下进行，来看看我们的部署流程：

首先我们需要在本地构建生成要部署的代码包，然后先scp到堡垒机（跳板机，相信大部分公司为了安全都会有），然后在登录我们的跳板机，然后scp到目标机器。这种工作一次两次还好，每天都这样简直是噩梦。

是到，稍微有经验的人就会想到为什么我们不用shell脚本来做这个事情，这的确也是我们马上就做的.我们通过expect脚本来进行自动完成从本机将代码传到堡垒机再传到目标机器的工作。我们写了一个叫做wdfe的nodejs命令行程序，在本地构建完成后，直接运行wdfe deploy test1就把代码部署到test1上，其他环境类似。这样我们每次构建部署只要2行命令

1. npm run build test1

2. wdfe deploy test1

这个命令行程序大大减少了我们的体力劳动。

第二步：平台初建，先解决现有问题。

有了命令行程序我们的效率大大提升，但是命令行程序其实有一些局限性，比如：

1.命令行程序的维护问题，每次更新（有可能是部署目标机器变化等）需要确保每个人都更新版本。

2.只能全量更新。

3.本地构建带来一些代码不同步的问题。

有的局限性在我们这样的团队状况下会有很致命的问题。比如由于历史问题，我们的项目工程是一个多人维护的超大工程，并且每天上线好几次的更新速度使得我们只能走部分文件上线这条路（已经不敢全工程上线），所以wdfe deploy这种全工程上线的方式我们短时间内无法实施（产品节奏，人力都是问题），只能用在测试环境。但人工挑出上线文件这种方式的确也是人神共愤，比如有一次修改较多，有人修改了几十个文件，则这个人需要从大工程里手工挑出这几十个文件，出错概率非常大。所以当时上线之后马上补单的事情经常发生。为了解决这个问题（其实说准确点叫缓解），我们用nodejs写了一个部署系统，部署系统会列出来从上次部署到本次部署期间，代码仓库有哪些文件是修改了的。通过界面列出来让部署者选择本次要部署的文件，这样能把这部分体力活减少90%，下面这张图是一个挑选部署文件界面（这个功能被我们一直保留到现在，因为还是有可能在某种特殊的情况下单独部署一个文件）：

第三步：拆分项目，完善部署平台，让部署变得顺滑。

通过前面两步我们通过工具和平台，大部解决了我们的当时团队在构建部署上的痛点，减少了大量重复的体力劳动。我们接着进行了第三步，让团队在构建部署上不再耗费心力。

首先我们看看第二部完成后，团队在工程化上的需求有哪些和我们的解决办法

支持全量部署，不用挑选部署文件，当然也支持部分文件部署（这个是工程代码组织问题，需要通过拆分项目解决，但是拆分项目到细粒度，就更需要部署平台的支持，比如一键部署多个项目多个机器）

针对这一条我们组织人力对项目进行拆分成多个子项目，各个子项目间无依赖，可以自行构建自行部署。并且在部署上提供多机器，多项目一键部署功能。

2.测试环境提测以后，有办法解决测试环境覆盖问题

首先统一收拢部署入口，所有部署必须经过部署平台，然后在部署平台部署完成后给部署人一个选项，是否锁住不让别人部署，解决覆盖问题：

3.上线前需要了解本次上线都需要列出来，放心上线

多人维护的项目，我们在部署的时候总是想确认那些人修改了哪些文件，避免遗漏我们通过提交日志和diff来给部署的同学非常清晰的说明。在部署前的checkout这一步，我们把本次上线到上次上线间，每个成员的修改次数，修改记录，每个文件的变化都列出来，并且可以细致到每一次修改

4.方便的添加项目，添加目标机器。

项目，部署机器的添加修改，都非常简单，增加一个项目和一个目标机器只要几分钟时间。拆分项目，添加修改部署目标机器完全没有心里负担

5.构建和部署无关化，支持项目自由选择技术栈。

构建完全有工程自己决定,部署平台只负责调用构建命令，并将构建结果按照规则部署到相应机器的相应目录下

部署平台的部署流程如下：

经过这一步，我们基本形成了我们自己的部署工程化体系，构建部署不再是我们团队成员的负担。并且我们还添加了部署统计这样有趣的模块，让大家对我们项目和人员部署情况有一个大概的了解。

最后我们其实把这个平台开源出来放到了github上，项目名字ideploy(希望大家爱上部署。。。)，希望我们的这些实践能帮到一些跟我们一样有过或者正在经历痛苦的公司：https://github.com/wdfe/ideploy ，也可以通过底部阅读原文进入项目主页