当部署失败时
部署失败后，Coroid 对环境中运行的内容认知并不会改变。该部署步骤会展示失败的尝试记录以及对应的流水线运行链接。修复问题根源后，若检查项已过期则重新执行检查，随后再次发起部署。每次尝试都会留存于版本的历史记录中。
若某次尝试出现卡顿现象，请在重试前先查看 CI/CD 中的运行记录及上报令牌。通常缺少上报数据意味着令牌或事件格式存在问题，而非部署真的失败了。
当健康状态需予以关注时
部署成功后，若已发布对应的金丝雀质量图谱，Coroid 会运行该项目对应的金丝雀质量图谱（带deployment_canary触发器的质量图谱）。若金丝雀检测失败，则会显示需予以关注在健康步骤中。此次部署仍会被视为成功，因为对应提交确实已部署到环境中。请查看金丝雀的检测结果及流水线日志，随后要么通过新版本继续修复，要么回滚至之前的提交版本。
回滚至稳定的提交版本
- 2.4.0版本正在生产环境中运行已部署，但金丝雀检查未通过需处理
- 选择一个此前在此环境运行正常的发布版本
- 2.3.1生产环境中上一个正常的发布版本运行正常
在当前已部署的版本页面中，打开健康选项查看对应环境的恢复之前的稳定提交版本。该选项会列出此前在该环境部署且通过健康检查的早期版本。
- 您的流水线已与 Coroid 对接。选择请求回滚，输入指向稳定提交版本的分支或标签，并说明回滚原因。Coroid 会验证该引用是否有效，随后为早期版本启动新的运行流程。只有当流水线确认部署成功时，环境才会切换回原版本。
- 您的流水线可自主运行。在此处回滚。若系统能上报部署结果，Coroid 会自动记录该结果。若无法上报，请选择记录外部回滚操作，针对稳定的版本进行记录。Coroid 会验证您要替换的版本确为当前运行的版本，且目标版本已通过健康检查。
原始部署记录与回滚记录均会保留在历史记录中。
批量发布多个项目
部分变更会涉及多个项目，例如新的 API 及其对应的应用程序。在版本列表中，选择协调发布流程，为其命名，并按发布顺序为每个项目挑选对应的版本。
发布流程是一种共享视图，并非单次部署。每个版本各自保留独立的提交记录、检查项、审批流程及流水线，且可从各自的页面分别发起部署。发布流程会显示部分已发布，此时部分项目尚未将版本部署到对应环境，因此剩余工作仍会清晰展示。