第七阶段：发布（Ship）
目标：预发布环境与线上完全一致，每次部署都平淡无奇，上线当天具备回滚能力，且上线后的第一周受到监控。
所有者运行部署。 代理负责准备、检查和解释。除非所有者明确要求执行该操作，否则代理不得 SSH 到服务器、运行 deploy-safe.sh、更改 DNS 或触碰 Cloudflare。deploy-safe.sh 需要一个终端和一个手动输入的提交 ID，因此代理无法独立完成一次部署。
步骤
- 预发布环境（
references/deploy-and-launch.md，“Staging”）：在线上主机上拥有自己的文件夹和数据库，WP_ENVIRONMENT_TYPE=staging，位于 Cloudflare Access 之后，并提供用于咨询的测试收件箱。 - 加固每个服务器：使用项目的
docs/reference/DEPLOY_HARDENING.md。将结果记录到docs/reference/SECURITY_PRELAUNCH.md中。 - 边缘配置：使用
references/cloudflare-edge.md中的 Cloudflare 设置。在旧主机前启用代理之前，先测试一下：某些主机根据 IP 进行限速，可能会屏蔽 Cloudflare。 - 部署代码，仅限所有者操作：
- 根据示例填写
deploy/targets.conf； - 运行
scripts/deploy-safe.sh <commit> --target staging --dry-run，阅读变更列表，然后不带--dry-run再次运行； - 在已有代码的服务器上首次运行时，需要加上
--assume-live <commit>。
- 根据示例填写
- 单独部署内容。
- 代码绝不携带价格、页面或法律文本。
- 每次变更记录为
docs/data/content-changes/<date>-<topic>.json（包含每个字段变更前后的值）。 - 通过
scripts/apply-content-change.sh <file> --target staging（试运行）应用，然后使用--apply。 - 在任何数据库导入或移动之后，运行
scripts/check-emoji.sh --target <env>。
- 发布审计：针对预发布环境运行 launch-auditor 代理，修复失败项，然后再次运行直到通过。
- 割接计划。 根据
references/deploy-and-launch.md中的“Cutover”编写割接计划。所有者批准日期和时间；如果网站已接受预订，业务合作伙伴也需要批准。 - 正式上线：部署到线上环境，针对线上环境运行 launch-auditor，将站点地图提交给 Search Console，向真实收件箱发送一条真实的测试咨询。
- 监控 7 天：错误、404 错误（添加重定向）、表单收件箱、分析数据、Search Console 覆盖率。
检查点（在 SITE_STATUS.md 中勾选）
- 预发布环境位于 Access 之后，设置 noindex，邮件已保护
- 安全加固已应用并记录
- 安全部署到预发布环境；冒烟测试通过
- launch-auditor 在预发布环境和线上环境均通过
- 割接计划已批准（日期、回滚方案、邮件/MX 已检查）
- 7天监控已完成
影响这些规则的事故
- 一个代理修改了线上价格、发布了 AI 编写的条款并部署了未审查的功能，其报告遗漏了这次部署。此后：部署只能来自合并后的提交，通过脚本执行，由人工输入，生产环境 SSH 密钥每次使用都需要确认。
- 预发布环境上的联系表单使用测试密钥发送到了第三方表单服务，因此咨询进入了测试收件箱。上线前，在线上发送一条真实的咨询，并确认其已到达。
- 分析工具处于“精简”模式，连续数周未统计欧盟访客，导致核心市场被隐藏。在第一天检查设置。
- 一次长时间部署（39 个提交）因
pipefail下git log | head产生的 SIGPIPE 而停止。脚本现在先捕获输出。 - 一次服务器数据库导入将表情符号变成了
????。每次导入后运行check-emoji.sh。