技能介绍

要解决的问题

做过几个项目的 CI/CD 的人都会遇到同样的困境：GitHub Actions、GitLab CI、Jenkins 各写一套部署脚本，镜像构建参数、Kubernetes 清单模板、数据库迁移步骤散落在不同仓库里，复制粘贴几轮之后，staging 能跑的 production 不一定能跑。配置靠环境变量硬编码，回滚只能靠手动 kubectl rollout undo，出问题时先翻聊天记录找上一次谁手动改了什么。

这个技能如何工作

核心思路是把部署收敛到一份声明式配置。技能读取项目根目录下的 deploy.yaml，按同一套流程驱动不同流水线：

镜像构建与推送：从 deploy.yaml 读取镜像 tag 策略，构建并推送到镜像仓库；
清单模板化：Kubernetes 清单按 kustomize 风格渲染，配合环境相关配置生成对应变体；
迁移执行：内置数据库迁移运行器，按序执行并记录状态；
配置生成：按目标环境产出差异化配置，避免手工改配置文件；
健康检查与回滚：部署后跑健康检查，失败时自动回滚；
通知：通过 Slack / Teams / DingTalk 推送部署结果。

安全设计与适用边界

这个技能在安全上做了三道闸：默认先跑 dry-run（必须显式传 --no-dry-run 才真正部署）；生产环境要求显式确认目标环境；健康检查失败时自动回滚。这意味着它适合标准化的三件套流水线（GitLab CI、Jenkins、GitHub Actions 都在覆盖范围内），但 deploy.yaml 的结构约束了能表达的部署模式——需要多阶段审批流或复杂金丝雀策略的项目，仍要回到自己的编排里。