类型：代码托管平台
简介：只支持Git作为唯一的版本库格式进行托管，故名GitHub。
把代码推到 main 后自动部署很方便，但生产环境不应该完全依赖一次提交触发。站点、API、文档平台或下载页一旦部署错误，影响的是实际访问。GitHub Environments 可以在 Actions 部署流程中增加环境概念，把 staging、production 等环境拆开管理，并为生产环境加入审批、Secrets 和部署记录。
一、Environments解决的不是语法问题
很多团队把部署失败归因于 YAML 写错，其实更常见的问题是环境边界不清。测试环境和生产环境使用同一组变量，任何人合并后都能部署生产，Token 分散写在仓库 Secrets 里，出了问题也很难追踪是谁触发了哪次发布。
Environments 的价值是把“部署到哪里”变成明确对象。staging 可以自动部署，production 可以要求人工批准；测试环境使用测试 Token，生产环境使用生产 Token。权限边界清楚后，部署流程才更稳。
二、创建staging和production环境
进入仓库 Settings，找到 Environments，新建 staging 和 production。环境名称会在 workflow 中引用，例如：
environment: production
当 job 指定 environment 后，GitHub 会把该 job 关联到对应环境。环境页面可以查看部署记录，也可以配置保护规则和环境级 Secrets。
三、给生产环境加审批
production 环境可以设置 Required reviewers。开启后，部署 job 到达生产环境前会暂停，等待指定人员批准。批准后 job 才继续执行部署步骤。
这个机制适合生产发布、重要文档站更新、下载文件替换、商用站点部署等场景。审批不是为了拖慢流程，而是给高影响操作增加最后确认。若只是部署到 staging，通常可以不设审批，让开发快速验证。
四、环境级Secrets比全仓库Secrets更清晰
仓库 Secrets 对所有 workflow 可见范围较宽，而环境级 Secrets 只在指定 environment 的 job 中可用。例如 STAGING_API_TOKEN 放在 staging，PRODUCTION_API_TOKEN 放在 production。这样即使测试部署脚本出错，也不容易误用生产密钥。
命名时不要把真实密钥值写进 workflow。workflow 只引用 secrets.NAME，具体内容保存在 GitHub 设置里。多人协作时，也不应通过聊天工具传递生产密钥。
五、workflow中如何引用环境
一个常见部署 job 可以这样组织：先构建，再部署到 staging；生产部署单独 job，依赖构建结果并指定 production。生产 job 触发后等待审批。这样构建和部署分离，环境边界更清楚。
如果项目需要手动选择环境，可以结合 workflow_dispatch inputs，让维护者选择 staging 或 production。但输入值要做限制，不要让任意字符串直接决定部署目标。
六、与分支规则配合使用
Environments 不是替代分支保护。更稳妥的生产流程是：main 分支受保护，必须 PR 合并；部署 workflow 只在 main 或 tag 触发；production 环境再要求审批。这样代码进入主分支和发布到生产环境都有控制点。
如果允许任意分支部署生产，即使 production 有审批，也可能把未审查代码发布出去。环境保护要和分支策略一起设计。
七、部署记录有什么用
每次关联 environment 的 job 都会形成部署记录。出现线上问题时，可以回看最近一次 production 部署是谁触发、哪个提交、是否通过审批。相比只看 Actions 列表，环境部署记录更贴近发布排查。
如果部署脚本支持回滚，可以在文档中记录如何回到上一版本。GitHub Environments 本身不自动回滚，但它能把发布过程留痕，方便团队快速定位。
八、适合站长项目的做法
静态站、文档站、工具官网可以先设置 staging 自动部署，用于预览页面；production 需要负责人审批后再上线。下载页、价格页、文档首页这类高影响页面更适合纳入生产审批。普通内容页如果每天更新频繁，可根据站点实际情况简化流程。
GitHub Environments 的重点不是把部署做复杂，而是让不同环境的风险级别可见。测试环境追求快，生产环境追求稳，两者分开管理，部署流程才不容易失控。
九、staging不是可有可无的中间站
很多项目只有 production，一个 workflow 跑完就直接上线。这样部署链路短，但任何配置错误都会直接影响线上。staging 的意义不是多一个环境名，而是给构建产物、环境变量、访问权限和页面效果一个提前验证位置。
静态站可以把 staging 部署到预览域名，应用服务可以使用测试数据库和测试 API。只要 staging 与 production 的部署方式尽量接近，就能提前发现路径、权限、环境变量和资源引用问题。若 staging 与生产完全不同，它的验证价值就会下降。
十、审批人要知道自己在确认什么
生产环境审批不是简单点一下同意。审批人至少应查看本次部署对应的提交、PR、构建状态和变更范围。如果本次改动涉及配置、权限、支付、下载入口、首页或登录流程，就应更谨慎。
团队可以约定一个轻量确认清单：构建是否通过，预览环境是否正常，是否有回滚方案，是否在合适时间发布。这个清单不需要写进正文页面，但在团队协作中很有价值。没有确认动作的审批，只是把自动部署改成手动点击。
十一、环境变量命名要避免混淆
staging 和 production 的变量如果名称完全不同，workflow 会变复杂；如果值混在一起，又容易误用。常见做法是保持变量名一致，但放在不同 environment 下。例如部署脚本都读取 `DEPLOY_TOKEN`，staging 和 production 分别提供不同值。
这样 workflow 更干净，也能减少条件判断。维护者只需要确认 job 指向哪个 environment，就能知道使用的是哪一组密钥。环境级变量和 Secrets 配合使用，比在脚本里写大量 if 判断更稳。
十二、生产部署失败后的恢复思路
Environments 不自动解决失败，但能让恢复更有依据。失败后先看 job 停在审批前、部署中还是部署后验证阶段；再看对应提交和产物。如果部署脚本支持版本化发布，应优先回到上一个稳定产物，而不是临时在服务器上手改文件。
对站点类项目，建议保存最近几次构建产物或至少保留可回退的提交记录。GitHub 环境部署记录能帮助定位“哪次发布开始出问题”，回滚动作仍需要项目自身部署流程支持。
十三、多环境部署中的常见误区
有些项目虽然创建了 staging 和 production，但两个环境使用同一个数据库、同一个对象存储或同一个部署 Token，这样并没有真正隔离风险。测试环境的错误脚本仍可能改到生产资源。环境隔离至少应覆盖密钥、数据源、部署目标和访问域名。
另一个误区是把审批人设置成所有成员。审批范围过宽时，任何人都能批准生产发布，规则就失去意义。更合理的方式是让熟悉部署和业务影响的人负责审批，并在紧急情况下保留备用审批人。这样既不会单点阻塞，也不会让审批流于形式。
