Zadig

Zadig是 KodeRover 推出的云原生 DevOps 平台，可组织环境、构建、测试、部署和生产发布。对已经有 CI 工具的团队，它是否值得引入，取决于能否把一次生产变更固定为可追踪版本，并把审批、灰度、回滚和操作记录放进同一执行链。

发布前先固定“交付物清单”

每次版本记录代码提交、镜像摘要、服务配置、数据库变更、启动顺序和负责人，禁止在生产步骤临时使用浮动标签。Zadig 的版本与发布流程可关联环境、服务、镜像或 Chart；配置变化不能只保存在流水线参数中，还应有独立审阅差异和恢复值。

Stage 与 Task 按失败边界编排

官方工作流将 Stage 作为串行阶段，Stage 内可包含串行或并发 Task，任务类型覆盖构建、测试、部署及配置、数据变更等。快速单元测试可以并发，生产部署必须等待制品扫描、集成测试和人工批准。每个任务设置超时、资源限制和清理动作，失败时保留日志与输入版本。

发布计划锁定窗口与执行人

灰度策略要匹配流量能力

Zadig 文档列出蓝绿、金丝雀、分批灰度、Istio 等发布任务。选择前先确认集群、入口网关和服务是否支持对应切流；没有可靠请求标识或观测指标时，不应把“20%—60%—全量”当成安全保证。每一阶段绑定错误率、延迟和业务指标阈值，超过即停止并回滚。

每次发布保存一份证据包

证据包至少包含需求与审批链接、代码提交、镜像摘要、配置差异、测试结果、发布参数、观测面板和最终结论。灰度每一阶段记录开始结束时间、实际流量与阈值判断；人工跳过任务必须写原因。这样才能区分“流水线显示成功”和“新版本已达到业务验收”，也便于事故发生后复现当时输入。

回滚演练必须覆盖配置和数据

1. 发布一个可识别但低风险的版本；
2. 在灰度阶段注入可控失败，验证后续任务停止；
3. 执行平台回滚，确认镜像和服务配置恢复；
4. 检查数据库变更是否需要前向修复而非简单回退；
5. 导出发布记录，核对操作人、时间和审批链。

代码仓库、镜像仓库和 Kubernetes 凭据应分别授权。开源版、企业版和特定发布任务存在版本边界，正式迁移前需用当前安装版走完一次真实闭环。