GitHub Actions中为何将构建部署拆分为独立Job而非合并为同Job的不同Step

拆分为两个独立Job的优势 #

• 问题定位更高效：两个Job职责单一，build Job只负责构建相关逻辑，deploy Job只负责部署流程。如果流程失败可以直接根据失败的Job定位问题范围：构建失败直接查依赖安装、编译逻辑的问题，不需要翻部署相关的日志；部署失败也可以直接排除构建环节的问题，排查效率高很多。
• 构建产物可复用：构建完成后上传的dist制品可以被多个下游Job复用，比如后续要扩展多环境部署（同时部署到测试环境、预发环境、生产环境）、或者加构建产物扫描（比如漏洞检测、兼容性校验）的环节，不需要重复执行构建流程，既节省运行时间，也能保证所有下游环节使用的是完全相同的构建产物，避免多次构建带来的不一致问题。
• 敏感信息权限隔离：部署环节需要用到FIREBASE_TOKEN这类敏感凭证，拆分为独立Job后，build Job全程不需要接触这类敏感信息，哪怕构建环节用到的第三方Action存在安全漏洞，也不会泄露部署权限，风险控制更严格。
• 流程控制更灵活：可以独立对两个Job配置执行规则，比如可以给deploy Job增加人工审批环节，构建完成后需要审核确认产物没问题再触发部署；也可以单独配置两个Job的运行策略，比如构建失败后自动重试，部署失败不重试等，不需要修改整体流程结构。
• 运行资源可独立配置：虽然当前两个Job都用ubuntu-latest运行器，后续可以根据需求单独调整资源配置：比如构建环节需要大内存、高CPU的运行器提升编译速度，部署环节只需要低配运行器就能完成，分开配置可以避免资源浪费，降低运行成本。
• 构建产物可回溯：上传的构建制品会在GitHub上留存指定时长，后续线上出现问题时，可以直接下载对应commit的历史构建包排查问题，不需要重新拉取旧代码执行构建，既节省时间也能保证排查用的包和当时线上部署的版本完全一致。

内容的提问来源于stack exchange，提问作者Louis Coulet