[toc]

1. 开始

之前介绍了强化版的小程序持续集成 (opens new window)，解决了一些手动上传效率低下的问题。

但仍存在一些问题：

1. 耗时久，npm i执行时间长，在大型项目中尤为突出
2. 不支持pnpm，不能利用 pnpm 快 + 省空间的优势
3. 依赖存在污染风险，有时候会报xxx.wxss undefined的错误
4. 无法在本地用机器人账户上传

2. 解决

2.1. 耗时久的问题

之前流水线是写在一个脚本里的，脚本依次执行依赖安装、打包、ci上传等，也就是项目的依赖和ci依赖是一起安装的。

对于耗时久的问题，可以用pnpm解决，依赖安装可以由120s降到7s内。

但是miniprogram-ci并不支持pnpm (opens new window)，如何解决呢？

其实我们项目自身是支持pnpm的，只是这个工具不可以，那么可以分步进行，打包好之后交给ci工具即可，这样就解决了第1、2个问题。

另外ci工具的依赖是稳定的，可以固定一个环境，这样还可以解决第3个问题，即依赖污染问题。

需要注意的是，最后提交信息、版本信息需要获取到，并设置到全局变量中，因为打包和上传分离后，上传阶段已经拿不到原始仓库的信息了。

2.2. 变量冲突

上面提到的固定环境，会带来一个问题，就是不同项目的密钥、环境变量会发生冲突，甚至同一项目的分支、环境变量也会冲突，如何解决呢？

有两个方案：

1. 不直接用同一环境，而是不同流水线去复制这个环境的产物
2. 利用docker，上传、预览在docker容器中执行

两个方案我都实现了，并进行了对比。

第1个方案，优点是简单、快速，没有下载镜像、创建容器的过程，缺点是稳定性、灵活性差，只能在我的机器上跑，且仍有被误删、误改的可能性。

第2个方案，优点是稳定性、灵活性强，有版本控制，任何项目、团队都可以使用，缺点是速度较慢，构建环境准备过程最多会多耗时几十秒。

目前用的是第2个方案，构建环境并不会每次都销毁，也就是时间差距并没有那么明显，且稳定性更为重要。

2.3. 本地上传与预览

之前的执行方式是bash输出脚本，然后执行脚本，这样的问题是不直观，难调试。

现在做成CLI命令，可支持本地上传和预览。

3. 效果

CI稳定性更强，耗时缩短。

以其中一项目为例，之前耗时6分35秒，现在耗时1分38秒，缩短297秒，减少约75.2%。

4. 总结

本次优化，总结下来有下面几点：

• 任务解耦
• 支持pnpm
• 缓存依赖
• 支持CLI命令

总结下整个小程序CI，其由下面三个模块组成：

• 配置模块，配置密钥、分支、环境、机器人等
• 任务调度，监控配置、更新执行模块
• 执行模块，流水线+CLI，完成打包、上传、预览、上报等任务

麻雀虽小，五脏俱全。小程序CI搭建过程中体现的思想有：

• 配置驱动，灵活、易维护
• 不同模块之前解耦，易扩展，任何模块都可替代
• 不同任务之间解耦，保证各单元可测试性，以及整体的稳定性、可用性