Bitbucket Pipeline与Docker中放置yarn构建命令的选型咨询

以下是实际工程落地中这类写法的常见决策依据：

• 彻底锁定构建环境一致性
  所有构建步骤的运行环境完全由Docker基础镜像定义，不会受Bitbucket Pipeline运行时的环境变更影响——比如Pipeline的Runner悄悄升级了Node/yarn版本、预装了存在冲突的全局依赖，都不会干扰构建结果。不管是开发在本地手动跑docker build调试，还是后续把CI从Bitbucket迁到其他平台，只要用同一份Dockerfile，就能产出完全一致的镜像，不需要给每个运行环境单独对齐Node版本、系统依赖等构建前置条件。
• 构建缓存不绑定特定CI平台
  Docker自带分层缓存机制：只要package.json、yarn.lock文件没有变动，RUN yarn install对应的层就会直接命中缓存，不需要重复执行依赖安装。这套缓存逻辑不依赖Bitbucket的Pipeline缓存能力，本地反复构建、团队其他成员拉代码构建、切换CI系统时都能复用，不会被单一CI平台的缓存规则绑死。
• 规避跨环境构建产物的兼容问题
  如果在Pipeline里先执行yarn命令生成构建产物，再复制进镜像，很容易出现环境不匹配的问题：比如Pipeline的Runner用Debian系统，而你的运行时基础镜像是Alpine，node_modules里的C++扩展二进制文件就会直接跑不起来；另外node_modules目录包含海量小文件，在Pipeline步骤之间做文件传输、复制的时候，不仅速度慢，还容易出现权限不对、漏传隐藏文件、软链接失效等玄学问题。把构建步骤全放在Dockerfile里，所有文件操作都在同一个容器环境内完成，这类问题会少很多。
• 构建逻辑自包含，排查成本低
  单份Dockerfile就能完整覆盖从源码到可运行镜像的全流程，不需要同时对照CI脚本、Dockerfile两份配置梳理构建逻辑，后续排查构建问题、复现构建结果的时候，不用跨多个配置文件找逻辑，排查效率高很多。

针对你提到的把命令放在Pipeline里的两个优势，实际落地时完全可以通过Dockerfile的优化抵消劣势：

1. 缓存复用问题：Docker层缓存和Bitbucket Pipeline缓存并不冲突，你可以在Pipeline配置中开启Docker构建缓存目录的持久化，同时享受两边的缓存加速效果，构建速度不会比把命令写在Pipeline里慢。
2. 镜像体积问题：你担心的层数多、体积大的问题，完全可以通过多阶段构建解决：第一阶段专门用来装依赖、跑构建脚本，第二阶段只从第一阶段复制最终的构建产物和生产环境需要的依赖，构建过程中产生的缓存、开发依赖都不会进入最终镜像；另外只要把同类型的RUN命令适当合并、在命令末尾及时清理临时文件，也不会出现多余层导致体积膨胀的问题。

内容的提问来源于stack exchange，提问作者Tree Nguyen