使您的下一次部署可重复

收集可识别的输入

使用可在非生产环境中构建的应用、对源代码及其产物注册表的访问、带版本的配置 schema 和外部密钥存储。保留一个已知可用的发布版本。这些是您自动化流程的输入；PrivacyNodes 不通过本网站提供部署 API 或流水线运行器。

固定产物，而不是依赖可变标签，例如 latest。Docker 记录了摘要固定，用于标识精确的基础镜像，同时需要审慎审查更新。可复现性和打补丁都是责任：永远保留旧的易受攻击镜像并不是维护计划。

技术参考： Docker 构建最佳实践.

在更改流量之前编写发布记录

这是一份文档格式，而不是可执行脚本。使用经过审查的产物填写占位符。仅凭源代码修订无法描述环境变更。包括观察到的迁移时长、预期锁行为、配置差异和上一个可用的产物。

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

将记录存储在应用宕机时仍可访问的地方。引用受保护的恢复凭据，但不要包含其值。指定可以停止提升的维护人员，以及计划回滚不再有效的时点。

将准备与提升分开

先构建并检查产物。在启动新进程之前验证配置和密钥引用。仅应用为此发布审查过的 schema 步骤。在目标环境中启动新版本，并在切换流量之前检查依赖项；避免将未经审查的破坏性迁移与普通镜像更新合并进行。

使用 Compose 时，容器已启动并不代表就绪。有意义的健康检查和 condition: service_healthy 可以使依赖等待变得有用，但无法验证客户工作流。应用仍然必须处理启动后依赖项变得不可用的情况。

技术参考： Docker Compose 启动顺序.

验证的不只是端口变绿

对于报告 API，请检查一个经过身份验证的测试请求、一次针对预期模式的读取、一个小型排队导出以及对其文件的访问。使用专用的测试命名空间并抑制生产通知。检查重叠版本是否会导致计划工作意外重复。

在检查前写下预期输出：正确的账户范围、预期的示例记录、一个已完成的导出以及无未授权的跨账户数据。之后记录实际输出和耗时。如果工作进程反复失败或迁移导致 API 读取过时值，仅首页返回 HTTP 200 是不够的。

明确恢复决策

如果进程无法启动，请将流量保持在正常工作版本上。如果工作流检查失败，请停止推进并保留已脱敏的证据。与旧产物兼容的增量模式可能允许应用回滚。在不兼容的转换之后，旧代码可能不安全；请遵循经过审查的前向修复或数据恢复计划。

不要无限期重复失败的迁移。确定已提交的内容、重试是否安全以及用户是否在新模式下写入。 迁移指南 通过列变更来开发此边界。不要将回滚按钮的存在视为数据可以逆转的证明。

留下另一位维护人员可以遵循的记录

将已部署的产物和配置标识符与计划记录进行比较。保留检查、失败尝试和所选的恢复操作。根据明确的保留策略保留最后一个正常工作产物；在验证未完成期间不要移除它。

一次有用的演练可以让另一位授权维护者解释输入、重复检查并找到恢复说明，而无需搜索你的 shell 历史记录。它并不能证明零停机或未来成功。当模式、工作进程行为或依赖发生变化时，请重新审视。接下来，缩小 部署身份的权限.