1. 开始
之前介绍了强化版的小程序持续集成，解决了一些手动上传效率低下的问题。
但仍存在一些问题：
- 耗时久，
npm i执行时间长，在大型项目中尤为突出 - 不支持pnpm，不能利用 pnpm 快 + 省空间的优势
- 依赖存在污染风险，有时候会报
xxx.wxss undefined的错误 - 无法在本地用机器人账户上传
2. 解决
2.1. 耗时久的问题
之前流水线是写在一个脚本里的，脚本依次执行依赖安装、打包、ci上传等，也就是项目的依赖和ci依赖是一起安装的。
对于耗时久的问题，可以用pnpm解决，依赖安装可以由120s降到7s内。
但是miniprogram-ci并不支持pnpm，如何解决呢？
其实我们项目自身是支持pnpm的，只是这个工具不可以，那么可以分步进行，打包好之后交给ci工具即可，这样就解决了第1、2个问题。
另外ci工具的依赖是稳定的，可以固定一个环境，这样还可以解决第3个问题，即依赖污染问题。
需要注意的是，最后提交信息、版本信息需要获取到，并设置到全局变量中，因为打包和上传分离后，上传阶段已经拿不到原始仓库的信息了。
2.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搭建过程中体现的思想有：
- 配置驱动，灵活、易维护
- 不同模块之前解耦，易扩展，任何模块都可替代
- 不同任务之间解耦，保证各单元可测试性，以及整体的稳定性、可用性