claude-howto 的 DevOps 自动化插件 /deploy 命令详解从预检到健康检查的完整部署工作流【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto导读/deploy是 claude-howto 仓库中 devops-automation 插件 的核心斜杠命令它把「预检 → 构建 → 测试 → 部署 → 健康检查 → 团队通知」六步发布流程封装成一句可执行的 Agent 指令。本文以 deploy.md 为骨架结合插件的 Shell 脚本、Node.js 钩子、Subagent 与 Kubernetes MCP 配置完整还原这条命令在 Claude Code 中的真实执行链路让读者既能直接上手/deploy staging//deploy production也能理解每一步背后的实现原理。命令概览一句话触发完整发布流水线在 Claude Code 中安装 devops-automation 插件后/deploy会作为一条可用斜杠命令注册进会话。命令的声明元数据位于 commands/deploy.md 的 YAML frontmatter--- name: Deploy description: Deploy application to production or staging ---name命令名/deploy即由它派生description告知 Claude Code 该命令的职责边界——将应用部署到生产或预发布staging环境。命令正文定义了一个 6 步执行工作流Run pre-deployment checks运行部署前检查Build application构建应用Run tests运行测试Deploy to target environment部署到目标环境Run health checks运行健康检查Notify team on Slack在 Slack 通知团队这 6 步不是抽象口号插件目录下每一份脚本、钩子、Agent 配置都能与之对应。下面逐层展开。前置条件与安装/deploy的可用性依赖以下环境见 插件 README 的 Requirements 一节依赖说明Claude Code 2.1插件机制的运行时要求Kubernetes CLIkubectl用于执行kubectl apply、kubectl rollout等集群操作集群访问配置需要可用的 kubeconfigKubernetes 访问配置通过环境变量指定export KUBECONFIG~/.kube/config安装插件本身只需一条命令/plugin install devops-automation六步部署工作流的实现映射第 1 步部署前检查 —— pre-deploy 钩子每次部署开始前Claude Code 会先触发 hooks/pre-deploy.js。这段 Node.js 脚本承担两道硬性校验// 检查 kubectl 是否已安装 execSync(which kubectl, { stdio: pipe }); // 检查是否已连接到集群 execSync(kubectl cluster-info, { stdio: pipe });任何一步失败都会process.exit(1)直接中断部署并输出明确的错误原因如❌ kubectl not found. Please install Kubernetes CLI.。这意味着「工具缺失」和「集群不可达」两类问题在真正触碰集群之前就会被拦截避免部署到错误或失效的目标。第 24 步测试、构建与部署 —— deploy.sh核心自动化逻辑在 scripts/deploy.sh 中。脚本开头set -e保证任何一步失败立即终止配合目标环境参数ENV${1:-staging}不传参时默认目标为staging传production则部署到生产环境对应/deploy production。随后脚本按顺序执行测试、构建与部署# 测试 npm run lint npm test # 构建 npm run build # 部署把目标环境的 Kubernetes 清单应用到集群 kubectl apply -f k8s/$ENV/值得注意的关键设计Kubernetes 清单按环境分目录存放k8s/staging/与k8s/production/kubectl apply -f k8s/$ENV/通过同一份脚本、不同的目录参数即可切换目标环境这是「一个命令管理多环境」的典型实现。第 5 步健康检查 —— deploy.sh 内建探测部署完成后脚本先等待 10 秒让 Pod 就绪再对目标环境的应用健康端点发起 HTTP 探测sleep 10 curl -f http://api.$ENV.example.com/healthcurl -f在返回非 2xx 状态码时视为失败结合set -e使部署整体失败退出——健康检查不通过就不会输出「部署成功」的结论。更完整的健康画像则由 scripts/health-check.sh 提供它同时检查三层API 层curl -sf http://api.$ENV.example.com/health数据库层pg_isready -h db.$ENV.example.comKubernetes 层统计指定命名空间下Running状态的 Pod 数与总数输出ready/total/status命令见 commands/status.md正是围绕这一能力展开覆盖 Pod 状态查询、数据库连接、API 响应时间、错误率与资源利用率。第 6 步团队通知 —— post-deploy 钩子与 Slack部署与健康检查通过后进入收尾阶段。post-deploy 钩子hooks/post-deploy.js负责等待 Pod 全部就绪并触发冒烟测试execSync(kubectl wait --forconditionready pod -l appmyapp --timeout300s, { stdio: inherit });--forconditionready等待匹配appmyapp的全部 Pod 进入 Ready 状态--timeout300s300 秒超时超时则process.exit(1)报错就绪后执行冒烟测试脚本中预留了测试命令插入点。最后Claude Code 依据工作流第 6 步向团队 Slack 频道发送部署结果通知。Subagent 协作deployment-specialist六步工作流中Claude Code 会把部署操作委派给专用 Subagent。插件内置的 agents/deployment-specialist.md 声明了其能力边界--- name: deployment-specialist description: Handles all deployment operations tools: Read, Write, Bash, Grep ---它专精于蓝绿部署Blue-green、金丝雀发布Canary、回滚流程、健康检查与数据库迁移等部署运维操作工具集限定为Read / Write / Bash / Grep——足以读取清单、执行脚本、分析日志但不会越权改动生产数据。Kubernetes MCPAgent 观察集群的通道部署过程需要 Agent 实时观测集群状态这依赖 MCP 集成。mcp/kubernetes-config.json 是标准的 MCP 服务器配置{ mcpServers: { kubernetes: { command: npx, args: [modelcontextprotocol/server-kubernetes], env: { KUBECONFIG: ${KUBECONFIG} } } } }通过npx启动modelcontextprotocol/server-kubernetesMCP 服务器KUBECONFIG环境变量把第 3 节导出的集群配置透传给 MCP 服务器使 Claude Code 能查询 Deployment、Pod 状态并监控发布进度。完整执行链路与结果汇总综合插件 README 中给出的示例工作流/deploy production的端到端执行顺序为User: /deploy production Claude: 1. Runs pre-deploy hook (validates kubectl, cluster connection) 2. Delegates to deployment-specialist subagent 3. Runs deploy.sh script 4. Monitors deployment progress via Kubernetes MCP 5. Runs post-deploy hook (waits for pods, smoke tests) 6. Provides deployment summary Result: ✅ Deployment complete Version: v2.1.0 Pods: 3/3 ready ⏱️ Time: 2m 34s可以看到钩子做门禁第 1、5 步、脚本做执行第 24 步、MCP 做观测、Subagent 做决策、Slack 做通知——各组件职责单一、串联成一条可审计的流水线最终以「版本号 Pod 就绪数 耗时」的结构化摘要收尾。回滚与常态监控部署闭环的另一半/deploy只是 DevOps 闭环的一半。发布失败时插件提供 commands/rollback.md 对应的/rollback命令其底层脚本 scripts/rollback.sh 先读取发布历史再执行回滚# 获取上一个发布版本号 PREVIOUS$(kubectl rollout history deployment/app -n $ENV | tail -2 | head -1 | awk {print $1}) # 回滚到上一版本 kubectl rollout undo deployment/app -n $ENV # 等待回滚完成并做健康检查 kubectl rollout status deployment/app -n $ENV sleep 5 curl -f http://api.$ENV.example.com/health回滚后同样执行健康检查与/deploy形成「发布—验证—回滚—再验证」的完整闭环日常巡检则交给/status与/incident命令。实践建议基于上述实现使用/deploy时值得注意环境隔离为 staging 与 production 分别维护k8s/env/清单目录部署目标由命令参数决定避免配置漂移门禁前移pre-deploy 钩子中的 kubectl 与集群连通性校验是廉价的第一道防线任何 CI 改动都应保证其通过后再继续健康端点必须真实curl -f http://api.$ENV.example.com/health依赖应用提供健康接口若健康端点返回 200 但业务异常建议扩展 health-check.sh 加入数据库连通性等更深层探测回滚演练rollback.sh依赖kubectl rollout history保留的发布历史正式环境应关闭或谨慎使用会清空历史的策略确保发布失败时总有上一稳定版本可回。总结/deploy是 claude-howto 展示「Claude Code 插件如何将运维经验工程化」的代表性样例一份仅 6 行的命令定义背后是钩子门禁、Shell 自动化、Subagent 分工与 Kubernetes MCP 观测四层能力的协同。理解了 deploy.md 与其配套的 脚本、钩子 和 Agent 配置你就能在自己的 Claude Code 工作区中复刻一条可落地、可审计、可回滚的自动化发布流水线。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考