尧图网站建设 
claude-howto 实战用 /deploy 斜杠命令自动化 Kubernetes 应用部署全流程【免费下载链接】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 插件07-plugins/devops-automation提供的核心斜杠命令之一它把部署到生产/预发布环境这一高频运维动作封装为一条可复用的指令。本文以 uk/07-plugins/devops-automation/commands/deploy.md 为主线结合仓库内的部署脚本、Hook、子代理与 Kubernetes MCP 配置逐层拆解一次完整部署背后的 6 个关键阶段读完你可以直接在自己的 Claude Code 工作流中复刻这套检查 → 构建 → 测试 → 部署 → 健康检查 → 团队通知的部署流水线。一、/deploy 是什么斜杠命令驱动的部署入口1.1 命令定义与作用域在 claude-howto 的插件架构中斜杠命令Slash Command是面向高频任务的快速入口。/deploy的定义位于 uk/07-plugins/devops-automation/commands/deploy.md其 front matter 声明了--- name: Deploy description: Deploy application to production or staging ---它解决的核心问题是把部署从一堆零散的 shell 命令收敛为一个语义明确的单一指令。无论是预发布staging还是生产production环境团队成员只需一条/deployClaude Code 就会按既定工作流执行部署。1.2 在插件体系中的位置/deploy属于 devops-automation 插件的能力矩阵与另外三个斜杠命令构成完整的 DevOps 闭环命令职责对应命令文档/deploy部署到生产或预发布环境deploy.md/rollback回滚到上一稳定版本rollback.md/status检查全系统健康状态status.md/incident处理生产事故incident.md从插件 README 的声明看插件还配套了deployment-specialist子代理、Kubernetes MCP 服务器、pre-deploy.js/post-deploy.jsHook 以及deploy.sh/rollback.sh/health-check.sh脚本/deploy正是把这一切编排起来的指挥中枢。二、部署工作流的 6 个核心阶段原命令文档将部署流程定义为 6 个阶段。下面逐一结合仓库源码说明每个阶段在真实执行时的具体动作与底层实现。阶段 1运行部署前检查Pre-deployment Checks文档定义Run pre-deployment checks源码佐证部署前的环境校验由 pre-deploy.js 完成。该 Hook 使用 Node.js 的child_process.execSync执行两项关键检查kubectl 是否已安装通过which kubectl探测 CLI 是否存在失败则输出❌ kubectl not found. Please install Kubernetes CLI.并以process.exit(1)终止部署是否已连接 Kubernetes 集群通过kubectl cluster-info验证集群连通性失败则输出❌ Not connected to Kubernetes cluster。只有两项检查全部通过输出✅ Pre-deployment checks passed部署流程才会继续。这种前置门禁设计避免了在工具缺失或集群失联时浪费时间。阶段 2构建应用Build Application文档定义Build application源码佐证构建动作在 deploy.sh 中执行# Build echo Building application... npm run build值得注意的是脚本开头使用set -e意味着任何一步失败都会立即中断脚本fail-fast 语义从机制上杜绝构建失败却继续部署的危险状态。阶段 3运行测试Run Tests文档定义Run tests源码佐证在构建之前deploy.sh 已经执行了质量门禁# Pre-deployment checks echo ✓ Running pre-deployment checks... npm run lint npm test即 lint 静态检查与单元测试是构建的前置条件。结合set -e若npm test返回非零退出码脚本会立即终止——测试不通过部署就不会发生。阶段 4部署到目标环境Deploy to Target Environment文档定义Deploy to target environment源码佐证环境由脚本的第一个参数决定默认值为stagingENV${1:-staging} echo Target environment: $ENV因此deploy.sh staging与deploy.sh production会分别部署到不同环境。实际的部署动作通过 kubectl 应用 Kubernetes 清单完成# Deploy echo Deploying to $ENV... kubectl apply -f k8s/$ENV/这里的k8s/$ENV/目录约定表明仓库为每个环境staging / production维护独立的一组 Kubernetes 资源清单kubectl apply -f以声明式方式应用这些配置保证幂等性重复执行结果一致。阶段 5运行健康检查Health Checks文档定义Run health checks源码佐证部署完成后deploy.sh 会先等待 Pod 启动再探测 API 健康端点# Health check echo Running health checks... sleep 10 curl -f http://api.$ENV.example.com/healthcurl -f在 HTTP 状态码为错误≥400时返回非零退出码从而在健康检查失败时让整个脚本失败。同时 post-deploy.js 提供了更深层的 Pod 就绪验证kubectl wait --forconditionready pod -l appmyapp --timeout300s这条命令最多等待 300 秒直到所有带appmyapp标签的 Pod 进入 Ready 状态超时则输出❌ Pods failed to become ready并退出随后进入冒烟测试smoke tests阶段。阶段 6在 Slack 通知团队Notify Team文档定义Notify team on Slack源码佐证仓库在 06-hooks/notify-team.sh 提供了通用的团队通知脚本可与部署完成节点对接。这是部署流水线的收尾动作目的是让团队成员第一时间获知部署结果而无需轮询环境状态。从插件 README 的示例输出可以看到部署成功后的结构化总结✅ Deployment complete Version: v2.1.0 Pods: 3/3 ready ⏱️ Time: 2m 34s三、完整调用链从 /deploy 到部署完成将上述阶段串联起来一次/deploy production的完整编排如下依据 devops-automation README 的 Example Workflow 与源码实现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关键环节的职责划分pre-deploy Hookpre-deploy.js负责工具与连接校验deployment-specialist 子代理deployment-specialist.md具备 Blue-green 部署、Canary 发布、回滚流程、健康检查、数据库迁移等专家能力负责编排部署策略deploy.shdeploy.sh执行 lint → test → build → apply → health-check 的串行动作Kubernetes MCPkubernetes-config.json让 Claude Code 具备读取集群状态、监控部署进度的能力post-deploy Hookpost-deploy.js等待 Pod 就绪并执行冒烟测试。四、环境配置与前置条件4.1 安装插件/plugin install devops-automation4.2 前置条件依据 devops-automation README 的 Requirements 声明Claude Code 2.1 及以上版本Kubernetes CLIkubectl已配置集群访问权限。4.3 Kubernetes 连接配置export KUBECONFIG~/.kube/config这一环境变量不仅被 kubectl 读取也会通过 kubernetes-config.json 透传给 Kubernetes MCP 服务器{ mcpServers: { kubernetes: { command: npx, args: [modelcontextprotocol/server-kubernetes], env: { KUBECONFIG: ${KUBECONFIG} } } } }从配置结构可以看到MCP 服务器通过npx启动modelcontextprotocol/server-kubernetes并继承宿主环境中的KUBECONFIG变量。这意味着只要在 shell 中正确导出了 KUBECONFIGClaude Code 的部署相关能力即可复用同一份集群凭据。4.4 典型使用方式/deploy staging # 部署到预发布环境 /deploy production # 部署到生产环境五、部署失败怎么办配套回滚与状态命令/deploy并非孤立存在。仓库为部署失败提供了配套的兜底能力5.1 /rollback一键回滚rollback.sh 实现了标准的 Kubernetes 回滚流程# Get previous deployment PREVIOUS$(kubectl rollout history deployment/app -n $ENV | tail -2 | head -1 | awk {print $1}) # Execute rollback kubectl rollout undo deployment/app -n $ENV # Wait for rollback kubectl rollout status deployment/app -n $ENV # Health check curl -f http://api.$ENV.example.com/health回滚同样以健康检查收尾验证回滚后的版本可用。rollback.md 定义的命令流程为识别上一部署 → 验证回滚目标健康 → 执行回滚 → 运行健康检查 → 通知团队。5.2 /status部署后的状态确认status.md 定义的状态检查覆盖查询 Kubernetes Pod 状态、检查数据库连接、监控 API 响应时间、审查错误率、检查资源利用率、报告整体健康。配套的 health-check.sh 给出了可执行的检查实现# Check API curl -sf http://api.$ENV.example.com/health # Check Database pg_isready -h db.$ENV.example.com # Check Pods kubectl get pods -n $ENV --no-headers三者API 健康端点、PostgreSQL 就绪探针、Pod 运行状态构成了部署后系统健康的可量化观测面。六、部署流程的可扩展点从源码结构看/deploy工作流在以下位置预留了扩展空间k8s/$ENV/ 清单目录为每个环境放置独立的 Kubernetes 清单可通过新增目录扩展更多环境如canarypost-deploy.js 的冒烟测试源码注释明确标注// Add your smoke test commands here可在该位置插入项目自定义的冒烟测试命令deployment-specialist 子代理其能力描述Blue-green、Canary、数据库迁移等说明可将更复杂的发布策略交给子代理编排notify-team.sh可配置为部署成功/失败时推送不同通知实现分级告警。总结/deploy斜杠命令将一次 Kubernetes 部署拆解为检查 → 构建 → 测试 → 部署 → 健康检查 → 通知六个阶段配合 pre/post Hook、deployment-specialist 子代理、Kubernetes MCP 与配套的 rollback/status 命令构成了一套在 Claude Code 中可直接复用的声明式部署工作流。其核心设计值得借鉴前置门禁拦截环境问题、set -e保证失败即停、健康检查作为部署成功的唯一判定标准——这套模式可以平移到任意基于 kubectl 或云原生工具链的项目中。相关文件索引命令定义deploy.md、rollback.md、status.md插件总览devops-automation/README.md部署脚本deploy.sh、rollback.sh、health-check.shHook 实现pre-deploy.js、post-deploy.js子代理与 MCPdeployment-specialist.md、kubernetes-config.json团队通知notify-team.sh【免费下载链接】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），仅供参考 claude-howto 实战：用 /deploy 斜杠命令自动化 Kubernetes 应用部署全流程
claude-howto 实战用 /deploy 斜杠命令自动化 Kubernetes 应用部署全流程【免费下载链接】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 插件07-plugins/devops-automation提供的核心斜杠命令之一它把部署到生产/预发布环境这一高频运维动作封装为一条可复用的指令。本文以 uk/07-plugins/devops-automation/commands/deploy.md 为主线结合仓库内的部署脚本、Hook、子代理与 Kubernetes MCP 配置逐层拆解一次完整部署背后的 6 个关键阶段读完你可以直接在自己的 Claude Code 工作流中复刻这套检查 → 构建 → 测试 → 部署 → 健康检查 → 团队通知的部署流水线。一、/deploy 是什么斜杠命令驱动的部署入口1.1 命令定义与作用域在 claude-howto 的插件架构中斜杠命令Slash Command是面向高频任务的快速入口。/deploy的定义位于 uk/07-plugins/devops-automation/commands/deploy.md其 front matter 声明了--- name: Deploy description: Deploy application to production or staging ---它解决的核心问题是把部署从一堆零散的 shell 命令收敛为一个语义明确的单一指令。无论是预发布staging还是生产production环境团队成员只需一条/deployClaude Code 就会按既定工作流执行部署。1.2 在插件体系中的位置/deploy属于 devops-automation 插件的能力矩阵与另外三个斜杠命令构成完整的 DevOps 闭环命令职责对应命令文档/deploy部署到生产或预发布环境deploy.md/rollback回滚到上一稳定版本rollback.md/status检查全系统健康状态status.md/incident处理生产事故incident.md从插件 README 的声明看插件还配套了deployment-specialist子代理、Kubernetes MCP 服务器、pre-deploy.js/post-deploy.jsHook 以及deploy.sh/rollback.sh/health-check.sh脚本/deploy正是把这一切编排起来的指挥中枢。二、部署工作流的 6 个核心阶段原命令文档将部署流程定义为 6 个阶段。下面逐一结合仓库源码说明每个阶段在真实执行时的具体动作与底层实现。阶段 1运行部署前检查Pre-deployment Checks文档定义Run pre-deployment checks源码佐证部署前的环境校验由 pre-deploy.js 完成。该 Hook 使用 Node.js 的child_process.execSync执行两项关键检查kubectl 是否已安装通过which kubectl探测 CLI 是否存在失败则输出❌ kubectl not found. Please install Kubernetes CLI.并以process.exit(1)终止部署是否已连接 Kubernetes 集群通过kubectl cluster-info验证集群连通性失败则输出❌ Not connected to Kubernetes cluster。只有两项检查全部通过输出✅ Pre-deployment checks passed部署流程才会继续。这种前置门禁设计避免了在工具缺失或集群失联时浪费时间。阶段 2构建应用Build Application文档定义Build application源码佐证构建动作在 deploy.sh 中执行# Build echo Building application... npm run build值得注意的是脚本开头使用set -e意味着任何一步失败都会立即中断脚本fail-fast 语义从机制上杜绝构建失败却继续部署的危险状态。阶段 3运行测试Run Tests文档定义Run tests源码佐证在构建之前deploy.sh 已经执行了质量门禁# Pre-deployment checks echo ✓ Running pre-deployment checks... npm run lint npm test即 lint 静态检查与单元测试是构建的前置条件。结合set -e若npm test返回非零退出码脚本会立即终止——测试不通过部署就不会发生。阶段 4部署到目标环境Deploy to Target Environment文档定义Deploy to target environment源码佐证环境由脚本的第一个参数决定默认值为stagingENV${1:-staging} echo Target environment: $ENV因此deploy.sh staging与deploy.sh production会分别部署到不同环境。实际的部署动作通过 kubectl 应用 Kubernetes 清单完成# Deploy echo Deploying to $ENV... kubectl apply -f k8s/$ENV/这里的k8s/$ENV/目录约定表明仓库为每个环境staging / production维护独立的一组 Kubernetes 资源清单kubectl apply -f以声明式方式应用这些配置保证幂等性重复执行结果一致。阶段 5运行健康检查Health Checks文档定义Run health checks源码佐证部署完成后deploy.sh 会先等待 Pod 启动再探测 API 健康端点# Health check echo Running health checks... sleep 10 curl -f http://api.$ENV.example.com/healthcurl -f在 HTTP 状态码为错误≥400时返回非零退出码从而在健康检查失败时让整个脚本失败。同时 post-deploy.js 提供了更深层的 Pod 就绪验证kubectl wait --forconditionready pod -l appmyapp --timeout300s这条命令最多等待 300 秒直到所有带appmyapp标签的 Pod 进入 Ready 状态超时则输出❌ Pods failed to become ready并退出随后进入冒烟测试smoke tests阶段。阶段 6在 Slack 通知团队Notify Team文档定义Notify team on Slack源码佐证仓库在 06-hooks/notify-team.sh 提供了通用的团队通知脚本可与部署完成节点对接。这是部署流水线的收尾动作目的是让团队成员第一时间获知部署结果而无需轮询环境状态。从插件 README 的示例输出可以看到部署成功后的结构化总结✅ Deployment complete Version: v2.1.0 Pods: 3/3 ready ⏱️ Time: 2m 34s三、完整调用链从 /deploy 到部署完成将上述阶段串联起来一次/deploy production的完整编排如下依据 devops-automation README 的 Example Workflow 与源码实现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关键环节的职责划分pre-deploy Hookpre-deploy.js负责工具与连接校验deployment-specialist 子代理deployment-specialist.md具备 Blue-green 部署、Canary 发布、回滚流程、健康检查、数据库迁移等专家能力负责编排部署策略deploy.shdeploy.sh执行 lint → test → build → apply → health-check 的串行动作Kubernetes MCPkubernetes-config.json让 Claude Code 具备读取集群状态、监控部署进度的能力post-deploy Hookpost-deploy.js等待 Pod 就绪并执行冒烟测试。四、环境配置与前置条件4.1 安装插件/plugin install devops-automation4.2 前置条件依据 devops-automation README 的 Requirements 声明Claude Code 2.1 及以上版本Kubernetes CLIkubectl已配置集群访问权限。4.3 Kubernetes 连接配置export KUBECONFIG~/.kube/config这一环境变量不仅被 kubectl 读取也会通过 kubernetes-config.json 透传给 Kubernetes MCP 服务器{ mcpServers: { kubernetes: { command: npx, args: [modelcontextprotocol/server-kubernetes], env: { KUBECONFIG: ${KUBECONFIG} } } } }从配置结构可以看到MCP 服务器通过npx启动modelcontextprotocol/server-kubernetes并继承宿主环境中的KUBECONFIG变量。这意味着只要在 shell 中正确导出了 KUBECONFIGClaude Code 的部署相关能力即可复用同一份集群凭据。4.4 典型使用方式/deploy staging # 部署到预发布环境 /deploy production # 部署到生产环境五、部署失败怎么办配套回滚与状态命令/deploy并非孤立存在。仓库为部署失败提供了配套的兜底能力5.1 /rollback一键回滚rollback.sh 实现了标准的 Kubernetes 回滚流程# Get previous deployment PREVIOUS$(kubectl rollout history deployment/app -n $ENV | tail -2 | head -1 | awk {print $1}) # Execute rollback kubectl rollout undo deployment/app -n $ENV # Wait for rollback kubectl rollout status deployment/app -n $ENV # Health check curl -f http://api.$ENV.example.com/health回滚同样以健康检查收尾验证回滚后的版本可用。rollback.md 定义的命令流程为识别上一部署 → 验证回滚目标健康 → 执行回滚 → 运行健康检查 → 通知团队。5.2 /status部署后的状态确认status.md 定义的状态检查覆盖查询 Kubernetes Pod 状态、检查数据库连接、监控 API 响应时间、审查错误率、检查资源利用率、报告整体健康。配套的 health-check.sh 给出了可执行的检查实现# Check API curl -sf http://api.$ENV.example.com/health # Check Database pg_isready -h db.$ENV.example.com # Check Pods kubectl get pods -n $ENV --no-headers三者API 健康端点、PostgreSQL 就绪探针、Pod 运行状态构成了部署后系统健康的可量化观测面。六、部署流程的可扩展点从源码结构看/deploy工作流在以下位置预留了扩展空间k8s/$ENV/ 清单目录为每个环境放置独立的 Kubernetes 清单可通过新增目录扩展更多环境如canarypost-deploy.js 的冒烟测试源码注释明确标注// Add your smoke test commands here可在该位置插入项目自定义的冒烟测试命令deployment-specialist 子代理其能力描述Blue-green、Canary、数据库迁移等说明可将更复杂的发布策略交给子代理编排notify-team.sh可配置为部署成功/失败时推送不同通知实现分级告警。总结/deploy斜杠命令将一次 Kubernetes 部署拆解为检查 → 构建 → 测试 → 部署 → 健康检查 → 通知六个阶段配合 pre/post Hook、deployment-specialist 子代理、Kubernetes MCP 与配套的 rollback/status 命令构成了一套在 Claude Code 中可直接复用的声明式部署工作流。其核心设计值得借鉴前置门禁拦截环境问题、set -e保证失败即停、健康检查作为部署成功的唯一判定标准——这套模式可以平移到任意基于 kubectl 或云原生工具链的项目中。相关文件索引命令定义deploy.md、rollback.md、status.md插件总览devops-automation/README.md部署脚本deploy.sh、rollback.sh、health-check.shHook 实现pre-deploy.js、post-deploy.js子代理与 MCPdeployment-specialist.md、kubernetes-config.json团队通知notify-team.sh【免费下载链接】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），仅供参考