DevOps 与持续交付：让变更可发布、可恢复
DevOps 把开发、交付和运行反馈放在共同责任中。开发者不仅交代码，还要知道如何构建、配置、观测和恢复；运行人员把失败模式和资源约束反馈给设计与测试。它不能简化成安装 CI 工具，也不意味着所有人共享无限生产权限。
订单导出在测试环境成功，上线后却可能因数据库压力、对象存储权限、任务并发或配置差异失败。交付流程要验证这些运行边界，且能把发布的代码、制品和配置追溯到同一次变更。
CI、持续交付和持续部署的区别
持续集成要求频繁合并小改动，自动构建和检查，尽早发现集成问题。持续交付要求变更持续处于可发布状态，生产发布可以保留人工决策；持续部署进一步使符合门禁的变更自动进入生产。拥有流水线不等于持续交付，手工点击发布也不必然违反持续交付。
图中检查和构建失败会回到实现，运行异常会先停止放量并恢复，再进入缺陷修复。部署成功只证明某些运行步骤完成，不能替代业务验收。需要检查任务能否生成、文件能否授权下载，以及在线业务是否受到影响。
围绕同一制品验证
流水线应尽量构建一次，后续环境使用同一制品标识，通过独立配置适配环境。每次发布记录提交版本、制品摘要、配置版本和部署结果。若测试环境和生产各自重新打包，会增加依赖或构建条件不一致的风险。
| 检查位置 | 订单导出的检查内容 | 失败后的处置 |
|---|---|---|
| 提交与 CI | 字段转换、状态规则、租户隔离、构建 | 修复差异，保留失败场景，重新验证 |
| 集成环境 | 数据库、队列、存储和下载鉴权 | 定位真实依赖与配置，禁止跳过验证 |
| 发布前 | 资源上限、配置、迁移兼容、恢复入口 | 补证据或调整方案，再决定发布 |
| 放量后 | 任务失败、队列积压、下载错误、在线延迟 | 停止放量，关闭入口或恢复兼容版本 |
工具命令随项目而定。检查应复用仓库已有脚本和流水线，具体 Git 与 CI 配置见 Git 与持续交付，容器和运行环境见 容器与云原生。方法页需要明确门禁职责，不必重复所有工具安装步骤。
发布和数据变化需要分开考虑
对可兼容的应用变更，可以通过灰度或功能开关逐步开放。开关关闭只阻止新导出，不一定停止已经接受的任务；队列中旧任务、运行中的 Worker 和已生成文件都要有明确处理方式。
若增加数据库字段，先做可兼容的扩展，再逐步切换读写，最后清理旧结构。直接删除字段后回滚应用通常无法恢复兼容。不可逆的数据操作需要备份、演练和前向修复方案，不能只写“失败回滚”。
恢复验收可以模拟 Worker 中断或存储不可写，确认任务状态可定位、重试不破坏数据、失败不会无限循环。重试次数、超时和告警阈值依据实际业务和负载确定，不从示例照搬。
运行反馈怎样进入开发
收集导出任务耗时、失败原因、队列等待、文件下载状态和数据库压力。日志应能关联请求和任务，但避免记录完整敏感文件内容。发现故障后先恢复服务，再复现问题、补回归检查、修复并验证，最后改善监控或配置。
衡量效果可观察变更前置时间、部署频率、失败变更和恢复时间，但要固定定义并结合业务看结果。发布更频繁而故障更难恢复，并不是有效改善。
AI 参与的范围
Agent 可以修改流水线草案、补检查、分析日志和准备发布证据。允许它执行哪些命令由环境和任务授权决定，代码实现完成不自动包含发布、删除资源或迁移生产数据的授权。AI 写出的部署脚本也要在对应环境验证。
完成交付应能回答：发布的制品是谁构建的，门禁覆盖了什么，运行异常怎样识别，谁决定停止放量，恢复是否经过验证。没有这些入口，自动化只是更快执行未知风险。