背景

现在线上环境每次上次都至少要花上30分钟以上。遇到紧急上线需求这个速度其实是非常不可接受的。

目标

优化整个上线环节的速度。

上线流程梳理

我们从 master 合并到 online 开始算。

1. 开始部署，这个不是很精确。目前老的service 是按照每 5min 轮询的方式来自动检测，意味着自动化的情况下，最长可能需要 5min，再加上如果当前有很多服务需要部署的话，还需要等待其他服务部署完才能部署。不过说是后面有计划逐步优化成，只要有合并就立刻触发构建。
2. 准备阶段，时间大概在 25s 左右。主要是远程去拉代码。
3. 前端编译，时间大概在 17min 15s 左右。包括安装依赖、静态编译、同步 sourcemap。
4. 镜像构建和验证，时间大概在 3min 10s 左右。包括镜像的构建、推送新的镜像、尝试拉新的镜像、删除历史老的镜像。
5. 发布阶段，时间大概在 12min 40s 左右。主要是 7 台线上机器部署，并发量是 1，串行部署，也就是每台机器的部署时间在 1min 49s。

从上面的数据可以看出，有很大一部分时间都花在了前端编译环节 和 发布阶段。

方案

从整个流程看，我们能优化的地方只有 开始部署、前端编译和发布阶段。

其他的就只能找运维去解决。不过优化空间非常的小。

针对开始部署

可以在代码合并后，第一时间去 service 发布平台点 build now 来减少。

针对发布阶段

我们总共有7台机器，其中一台是 preview，如果遇到特别着急上线的话。可以考虑切换到紧急上线状态，把并发度从 1 调整到 3，并且不部署 preview 机器。

这样一来，这个环节的整体上线时间相当于从 12min 40s 缩减到了 1min 49s * 2 = 3min 38s。

针对前端编译

整体思路依旧是部分部署的方式。

但是由于在准备阶段远程拉取的代码是没有 Git 的信息。

所以，我们需要做一些额外的处理，就是有一个地方能让我们控制是否需要执行这样的操作。

后续的编译可以考虑把能忽略的都忽略掉。比如 eslint 检测，sourcemap 上传。

理论上来说，如果只改动一个文件的话，理想情况下，1min 内是可以完成整个前端编译的。

最后

理想情况下，最快的部署时间大概会是：5s + 25s + 1min + 3min 10s + 3min 38s = 8min 18s 左右能完成整个线上部署。