尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Claude Code で `/deploy` コマンドを自作する:devops-automation プラグインのデプロイワークフロー完全ガイド

Claude Code で `/deploy` コマンドを自作する:devops-automation プラグインのデプロイワークフロー完全ガイド Claude Code で/deployコマンドを自作するdevops-automation プラグインのデプロイワークフロー完全ガイド【免费下载链接】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 Code のスラッシュコマンドとしてアプリケーションを本番環境productionまたはステージング環境stagingへデプロイするためのエントリーポイントです。本記事では、このコマンドが実行する 6 ステップのデプロイワークフローを、claude-howtoリポジトリに同梱される devops-automation プラグインのスクリプト・フック・サブエージェント・MCP 設定を併せて読み解きながら、実際の運用にそのまま流用できる形で解説します。読了後には、Claude Code 上で「検証 → ビルド → テスト → デプロイ → ヘルスチェック → 通知」の一連のリリース作業を自動化する方法と、その内部実装の全体像を把握できます。1./deployコマンドの定義と役割コマンドの実体は、deploy.md に記述された 1 つの Markdown ファイルです。このファイルの冒頭には、Claude Code がスラッシュコマンドとして認識するための frontmatterメタデータが定義されています。--- name: Deploy description: アプリケーションを本番環境またはステージング環境へデプロイする ---name: Deploy… この値がそのままスラッシュコマンド名/deployとして登録されます。description… Claude がユーザーの意図を解釈する際に参照する説明文です。ここに「本番またはステージングへデプロイする」と明記しておくことで、ユーザーが「本番に上げて」と自然言語で頼んだ場合でもコマンドが適切に選択されやすくなります。本体となる# Deploy Application以降には、Claude が実行すべきデプロイワークフローが番号付きリストで定義されています。デプロイ前チェックを実行アプリケーションをビルドテストを実行対象環境へデプロイヘルスチェックを実行Slack でチームに通知この 6 ステップが/deployの骨格です。以降の章では、各ステップがプラグイン内のどの実装と対応しているかを、リポジトリ内のソースコードを参照しながら掘り下げます。2. プラグインの全体像6 ステップを支える構成要素/deployは単体で動くわけではなく、devops-automation プラグインに含まれる複数の部品が連携して動作します。devops-automation の README には、次の構成要素が定義されています。カテゴリファイル役割スラッシュコマンドcommands/deploy.md/rollback.md/status.md/incident.mdデプロイ・ロールバック・健全性確認・障害対応の入口サブエージェントagents/deployment-specialist.mdほかデプロイ作業の専門担当ブルーグリーン、カナリア、ロールバック、DB マイグレーション等スクリプトscripts/deploy.sh/rollback.sh/health-check.sh実際のシェル処理ビルド、kubectl 適用、ヘルスチェックフックhooks/pre-deploy.js/post-deploy.jsデプロイ前後の検証・後処理Node.jsMCP サーバーmcp/kubernetes-config.jsonKubernetes クラスタとの連携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つまり、コマンド定義ファイルの 6 ステップは、フックの実行ステップ 1・5とスクリプトの実行ステップ 3に具体化され、サブエージェントと MCP サーバーがその全体を補完する構造になっています。3. ステップ 1・3deploy.sh に見る検証・ビルド・テスト・デプロイの実装ワークフローのうち「デプロイ前チェック」「ビルド」「テスト」「対象環境へデプロイ」は、シェルスクリプト deploy.sh に集約されています。#!/bin/bash set -e echo Starting deployment... # Load environment ENV${1:-staging} echo Target environment: $ENV # Pre-deployment checks echo ✓ Running pre-deployment checks... npm run lint npm test # Build echo Building application... npm run build # Deploy echo Deploying to $ENV... kubectl apply -f k8s/$ENV/ # Health check echo Running health checks... sleep 10 curl -f http://api.$ENV.example.com/health echo ✅ Deployment complete!3.1 環境の選択ENV${1:-staging}第 1 引数$1で対象環境を指定し、省略時はstagingにフォールバックします。これにより、/deployコマンドの引数/deploy staging//deploy productionがそのままスクリプトの引数として受け渡される設計です。なお、README の「Requirements」には Kubernetes CLIkubectlとクラスタへのアクセス設定が必要と明記されており、export KUBECONFIG~/.kube/configで設定を行います。3.2set -eによるフェイルファスト冒頭のset -eにより、lint・テスト・ビルド・kubectl applyのいずれかが失敗した時点でスクリプト全体が異常終了します。後続のデプロイ処理に進まないため、検証を通過していないコードが本番環境に流れるリスクを構造的に防いでいます。3.3 デプロイ対象の切り替えkubectl apply -f k8s/$ENV/は、k8s/staging/やk8s/production/といった環境別のマニフェストディレクトリを参照します。つまり、環境ごとの差分レプリカ数、リソース制限、シークレット参照などは YAML 側で管理し、スクリプトは共通処理として環境名だけを切り替えるという、シンプルで保守しやすい構成です。3.4 簡易ヘルスチェックkubectl applyの直後にsleep 10を挟み、Pod の起動を待ってからcurl -fで API の/healthエンドポイントを検証します。-fオプションにより HTTP エラー4xx/5xxは失敗扱いになるため、デプロイ直後の重大な障害をこの時点で検出できます。4. ステップ 1 の前段pre-deploy.js による前提条件の検証コマンド定義のステップ 1「デプロイ前チェック」は、deploy.sh内のnpm run lint/npm testに加え、Node.js 製フック pre-deploy.js でも実行されます。このフックはデプロイの前提となるツールと接続を検証します。async function preDeploy() { console.log(Running pre-deployment checks...); const { execSync } require(child_process); // Check if kubectl is installed try { execSync(which kubectl, { stdio: pipe }); } catch (error) { console.error(❌ kubectl not found. Please install Kubernetes CLI.); process.exit(1); } // Check if connected to cluster try { execSync(kubectl cluster-info, { stdio: pipe }); } catch (error) { console.error(❌ Not connected to Kubernetes cluster); process.exit(1); } console.log(✅ Pre-deployment checks passed); }which kubectl… kubectl バイナリの存在を確認。未インストールなら即座にprocess.exit(1)で中断します。kubectl cluster-info… 現在のクラスタ接続KUBECONFIG の有効性、認証状態を確認します。失敗時はエラーメッセージを出力して終了コード 1 を返すため、/deployのワークフロー全体が不正な状態で開始されるのを防ぎます。5. ステップ 4 の後段post-deploy.js による Pod 待機とスモークテストデプロイ適用後の「待機と確認」は、post-deploy.js が担います。// Wait for pods to be ready console.log(Waiting for pods to be ready...); try { execSync(kubectl wait --forconditionready pod -l appmyapp --timeout300s, { stdio: inherit }); } catch (error) { console.error(❌ Pods failed to become ready); process.exit(1); } // Run smoke tests console.log(Running smoke tests...); // Add your smoke test commands herekubectl wait --forconditionready pod -l appmyapp --timeout300s… セレクタappmyappに一致する全 Pod が ready になるまで最大 300 秒待機します。タイムアウト時は失敗扱いとなります。続いてスモークテストを実行する場所がコメント付きで用意されており、curlによる主要 API の応答確認などをここに追記してカスタマイズできます。deploy.sh内のsleep 10は即時的な確認、このフックはローリングアップデートの完了確認とスモークテストという、2 段構えでデプロイ後の安全性を確保している点が特徴です。6. ステップ 5 の補完health-check.sh による多層ヘルスチェックワークフローのステップ 5「ヘルスチェック」は、health-check.sh により API・データベース・Kubernetes Pod の 3 層に対して実施できます。#!/bin/bash echo System Health Check echo ENV${1:-production} # Check API echo -n API: if curl -sf http://api.$ENV.example.com/health /dev/null; then echo ✅ Healthy else echo ❌ Unhealthy fi # Check Database echo -n Database: if pg_isready -h db.$ENV.example.com /dev/null 21; then echo ✅ Healthy else echo ❌ Unhealthy fi # Check Pods echo -n Kubernetes Pods: PODS_READY$(kubectl get pods -n $ENV --no-headers | grep Running | wc -l) PODS_TOTAL$(kubectl get pods -n $ENV --no-headers | wc -l) echo $PODS_READY/$PODS_TOTAL readyAPI は/healthへのcurl -sf、データベースは PostgreSQL の接続確認ツールpg_isready、Pod はkubectl get podsの Running 数を集計し、それぞれが「Healthy / Unhealthy」「ready 数/合計」の形で結果を返します。このスクリプトは/deploy内のヘルスチェックを充実させる他、/statusコマンドstatus.mdの基盤としても利用できます。7. ステップ 4・6 を支える周辺要素サブエージェント・MCP・ロールバック7.1 deployment-specialist サブエージェントdeployment-specialist.md は、デプロイ作業全般を専門に扱うサブエージェントの定義です。ブルーグリーンデプロイ、カナリアリリース、ロールバック手順、ヘルスチェック、データベースマイグレーションを得意分野として列挙しており、/deploy実行時に Claude がこのエージェントへ作業を委譲しますfrontmatter でtools: Read, Write, Bash, Grepが指定されています。7.2 Kubernetes MCP サーバーkubernetes-config.json では、Kubernetes 操作用の MCP サーバーが定義されています。{ mcpServers: { kubernetes: { command: npx, args: [modelcontextprotocol/server-kubernetes], env: { KUBECONFIG: ${KUBECONFIG} } } } }npxでmodelcontextprotocol/server-kubernetesを起動し、KUBECONFIG環境変数を引き渡します。README のワークフロー例では「Monitors deployment progress via Kubernetes MCP」とある通り、デプロイ進行状況の監視に使用されます。MCP 全般の仕組みは 05-mcp/README.md を参照してください。7.3 万一に備える rollback.shデプロイに失敗した場合は、rollback.sh と/rollbackコマンドrollback.mdで前回の安定版へ復旧します。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/healthkubectl rollout undoで直前のリビジョンへ戻し、rollout statusで完了を待ってからヘルスチェックを実行する流れです。「デプロイを自動化するならロールバックも自動化する」という、運用上のセットとして整備されています。8. まとめ/deployが実現するエンドツーエンドのデプロイ自動化改めて、/deployコマンドの 6 ステップと実装要素の対応を整理します。ワークフローステップ対応する実装1. デプロイ前チェックhooks/pre-deploy.jskubectl・クラスタ接続検証scripts/deploy.sh内のnpm run lint2. アプリケーションをビルドscripts/deploy.sh内のnpm run build3. テストを実行scripts/deploy.sh内のnpm test4. 対象環境へデプロイscripts/deploy.sh内のkubectl apply -f k8s/$ENV/、進捗監視は Kubernetes MCP5. ヘルスチェックを実行deploy.sh内のcurl -fhooks/post-deploy.jsの Pod 待機/スモークテスト、詳細はscripts/health-check.sh6. Slack でチームに通知ワークフロー定義上の最終ステップ通知先やチャンネルは環境に応じてカスタマイズプラグインの導入は/plugin install devops-automation07-plugins/README.md、実行は/deploy stagingまたは/deploy productionです。前提条件は Claude Code 2.1 以上、kubectl のインストール、KUBECONFIG によるクラスタ接続設定ですREADME の Requirements 節。本記事で見たとおり、/deployは「コマンド定義Markdown シェルスクリプト Node.js フック サブエージェント MCP」という Claude Code プラグインの標準的な構成を体現した例です。この構成を自プロジェクトに移植する際は、k8s/$ENV/のマニフェストを自前のクラスタ構成に置き換え、post-deploy.jsのスモークテスト部分を自分のアプリケーションの検証コマンドに差し替えるだけで、実運用にそのまま適用できます。なお、本リポジトリの各翻訳ディレクトリja ほかではプラグインのドキュメントも多言語化されており、翻訳差分を確認する場合は TRANSLATION_NOTES.md を参照してください。【免费下载链接】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),仅供参考
返回列表