持续交付 / 持续部署
CD
中级通用持续交付和持续部署（CD）是把通过检查的代码持续推进到可发布状态或生产环境的流程。它们解决了每次上线都靠人手打包、传文件和执行步骤，容易漏做或做错的问题。
你可能会说：「我想改完网站代码后自动检查和打包，上线前能选择人工确认，稳定后再自动发布。」
动手看看订单页改版如何上线
1
开发者提交订单页改版代码，流水线自动启动检查，不用再靠人记得逐项执行。
要点代码改完后，CD 怎样把它送到用户面前？
- 1
先把发布步骤连成流程
你可以让代码合并后自动运行测试、构建应用，并准备部署包。这样每次发布走的是同一套步骤，不用临上线时再想起某条命令没执行。
- 2
人工确认决定交付还是部署
持续交付通常把版本准备到随时可发布，真正上线仍由人确认；持续部署则让通过预设检查的变更自动进入生产环境。两者的区别在最后这道发布决定由谁做。
- 3
检查通过不等于用户体验正常
比如 AI 工具更新了聊天页，测试通过后仍可能出现真实请求失败。我们还会关注上线后的监控，并准备回滚办法；流程自动化了，也得知道出问题时怎么停下和恢复。
容易混淆的地方
持续集成（CI）关注代码合并后能否通过构建和测试；CD 接着处理怎样把通过检查的版本送往发布。单次“部署上线”是一次操作，CD 则是让这类操作反复按约定流程发生。这里的 CD 可能指持续交付，也可能指持续部署，沟通时最好说清上线是否需要人工确认。
什么时候用
适合用
- 你维护一个经常改动的后台，希望每次合并后自动测试、构建，确认无误再发布给客户。
- 你运营一个频繁更新的在线工具，希望通过检查的网页改动自动上线，并能及时发现异常。
- 几个同事轮流发布同一个 App 后端，想用固定流程代替各自手动执行部署命令。
不适合用
- 你只在本机做一次性原型，没有服务器和实际用户；直接本地运行验证，比搭建 CD 流程更合适。
- 你要解决的是“这次报错发生在哪行代码”；先看报错与调用栈，CD 本身不能定位代码错误。
- 你只是偶尔更新一个手工托管的静态页面，当前能清楚地手动上传；先用简单的部署方式即可。
练一练选一个答案，看看解释
你们的网站每周更新几次。团队想让合并后的代码自动测试和构建，但由负责人看过预发布页面后再点发布。这属于哪种做法？
让 AI 帮你做复制给 AI Agent 直接用
请为这个网站设计持续交付流程：代码合并后运行测试并构建，部署到预发布环境；生产发布保留人工确认。请列出需要配置的步骤、失败时如何中止，以及上线后如何验证和回滚，先不要直接改动生产环境。