持续交付与持续部署的关键区别在于是否需人工确认上线：前者代码随时可上线但需手动触发，后者则全自动部署。CD流水线必须包含build、test、package、deploy四阶段，且各阶段有明确出口标准。
持续交付（CD）和持续部署（CD）不是一回事，关键区别在于“人按不按那个发布按钮”。
持续交付 vs 持续部署：就差一次人工确认
持续交付的目标是让每次通过自动化测试的代码都“随时能上线”，但是否上线由人决定。比如在 GitLab CI/CD 中配置了 production 阶段，但它被设为 needs_approval: true，那每次构建完就会卡在审批页，等运维或产品经理点“Approve”才走下一步。
持续部署则跳过这一步——只要 unit-test、integration-test、security-scan 全部通过，流水线自动执行 kubectl apply -f manifests/ 或调用 Azure App Service 的部署 API，5 分钟后用户就看到新功能了。
容易踩的坑：
Software Data Github Interact Developer Helper
下载
帮助用户满足已验证需求：代理用户在Clawhub上对GitHub式工作流有强烈需求，需要实用帮助修复bug、强化设置。
- 把“持续部署”当成“随便部署”：没配好回滚机制（比如没保留上一个
image: v1.2.3的 Helm Release），出问题只能手动删 Pod - 误以为“有 Jenkins 就算 CD”：只做了自动构建 + 单元测试，没连通制品库（如 JFrog Artifactory）和部署目标（如 Kubernetes 集群），其实只是 CI
- 环境不一致：开发用 Docker Compose 跑得好好的，生产用 K8s 却因 ConfigMap 加载顺序失败——这不是 CD 流程问题，是 IaC 没管住环境
CD 流水线必须包含的 4 个硬性阶段
一个真正可用的 CD 流水线不是“能跑就行”，而是每个阶段都有明确出口标准：
-
build：生成可复现的制品，比如带 Git SHA 的app.jar或myapp:v2.1.0-abc123镜像；禁止用latest标签直接推送到生产镜像仓库 -
test：至少含单元测试 + 集成测试；端到端测试（如 Cypress）建议放独立 stage，失败不阻塞主流程，但发告警 -
package：把构建产物存进制品库，并附带元数据（构建时间、触发分支、测试覆盖率）；GitLab CI 可用artifacts，Jenkins 推荐 Nexus +archiveArtifacts -
deploy：区分环境，比如staging自动部署，production必须满足两个条件才触发：① 上游 stage 全绿；②DEPLOY_WINDOW环境变量值为true（避免凌晨自动上线）
自动化部署失败最常见的 3 类原因
90% 的部署失败不来自脚本写错，而来自环境契约断裂：
-
Permission denied (publickey)：CI 机器用 SSH 部署到跳板机时密钥没配对；正确做法是用短期 Token（如 GitHub OIDC）换取云平台临时凭证，而非硬编码私钥 -
ImagePullBackOff：K8s 集群拉不到镜像，常见于没给节点配置imagePullSecrets，或镜像仓库权限策略改了但没同步更新 ServiceAccount - 配置覆盖错误：Helm upgrade 时用了
--set config.env=prod，却忘了--reuse-values，导致之前设的replicaCount被重置为默认值 1
真正的难点不在写 pipeline，而在让每次 git push 后，从构建、测试到流量切换的每一步都具备可观测性、可追溯性和可逆性——这些没法靠一个 YAML 文件解决，得靠日志打点、链路追踪、以及每次部署前强制运行的 smoke test。
