agentsclimarketplace
Sign in

Cicd deployment

Skill tdyzzsp47/claude-skills/skills/cicd-deployment

CI/CDパイプライン構築・デプロイ戦略・リリース管理をカバーするスキル。新規プロジェクトのCI設計から既存パイプラインの改善、デプロイ戦略の選定、リリース運用の整備まで幅広く対応する。From its SKILL.md

Install
npx -y skills add tdyzzsp47/claude-skills --skill cicd-deployment

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

9.5 KB, ~3.5k tokens by cl100k_base, as published. Nobody here has run it

CI/CD・デプロイ・リリース管理

目的

  • PR単位での自動品質チェック(lint/型/テスト)を整備し、mainを常にデプロイ可能な状態に保つ
  • 環境分離・シークレット管理・ロールバック手順を確立し、安全なデプロイを実現する
  • デプロイとリリースを分離し、機能公開タイミングをコードと切り離して制御する

使うタイミング

  • 新規プロジェクトでCIパイプラインをゼロから構築するとき
  • 既存のCIが遅い・不安定・属人化しているとき
  • デプロイ手順が手動で担当者依存になっているとき
  • ブルーグリーン・カナリアなどのデプロイ戦略を導入・見直すとき
  • セマンティックバージョニングやCHANGELOG運用を整備するとき

進め方

  1. 現状把握 — 既存のデプロイ手順・頻度・障害履歴を確認。手動ステップと自動化済みステップを区別する
  2. 環境構成を定義 — dev/staging/productionの役割と昇格フローを決める。設定値はすべて環境変数で注入する方針を確認
  3. CIパイプライン設計 — ステージ(lint→型チェック→テスト→ビルド)と所要時間目標(10分以内)を設計。キャッシュ・並列化の余地を洗い出す
  4. デプロイ戦略を選定 — 規模・リスク許容度に応じてIn-place/Blue-Green/Canaryを選ぶ。ロールバック手段を最初に決める
  5. DBマイグレーション手順を確定 — 後方互換マイグレーションを先に適用してから新コードをデプロイする順序を固定する([[database-design]])
  6. シークレット管理を整備 — CI/CDプラットフォームのシークレット機構を使う。コードやログに平文で出ないことを確認する([[security]])
  7. リリース管理を整備 — セマンティックバージョニング・gitタグ・CHANGELOGのルールを決める
  8. デプロイ後観測を組み込む — デプロイ通知・エラー率・レイテンシの確認フローを習慣化する([[monitoring-operations]])
  9. ロールバック訓練 — 手順書通りに実際にロールバックできることをstagingで検証する

設計の要点

CI

  • 10分以内を目標。遅いCIは無視される
  • キャッシュ(依存パッケージ・ビルドキャッシュ)と並列ジョブで高速化
  • mainへのマージ前にCI通過を必須条件にする(ブランチ保護ルール)
  • 「急ぎだから」でテストをスキップする習慣を作らない。スキップするなら意図を記録する

デプロイ戦略

戦略向いている規模・状況ロールバック
In-place個人開発・小規模・Vercel/Fly.io等PaaS前バージョンへの再デプロイ
Blue-Green中規模・ダウンタイムNG・切り戻し速度重視ルーティングを旧環境に戻す
Canary大規模・リスク低減・段階的トラフィック移行カナリア比率を0に戻す
  • デプロイとリリースの分離 — フィーチャーフラグで機能公開をコードデプロイと切り離す
  • 金曜夕方・深夜・連休前のデプロイを避ける。対応できる時間帯に実施する
  • 個人開発はVercel/Cloudflare Pages/Fly.ioのgit push連動デプロイで十分。Kubernetes導入は不要([[solo-development]])

リリース管理

  • セマンティックバージョニング: MAJOR.MINOR.PATCH。破壊的変更=MAJOR、機能追加=MINOR、バグ修正=PATCH
  • gitタグ(v1.2.3)でリリースポイントを記録する
  • CHANGELOGはユーザー視点で書く。コミットハッシュの羅列ではなく「何が変わったか・なぜ変えたか」を記す

成果物テンプレート

# パイプライン設計シート
stages:
  - name: Lint & Type Check
    trigger: PR作成・更新、mainプッシュ
    jobs:
      - eslint / ruff / tsc --noEmit
    goal_duration: 2分以内
    on_failure: PRブロック・Slack通知

  - name: Test
    trigger: PR作成・更新、mainプッシュ
    jobs:
      - ユニットテスト（並列）
      - 統合テスト
    goal_duration: 5分以内
    on_failure: PRブロック・Slack通知
    cache: node_modules / .venv / Goモジュール

  - name: Build & Package
    trigger: mainプッシュ、タグプッシュ
    jobs:
      - Dockerビルド or 静的ビルド
    goal_duration: 3分以内
    on_failure: デプロイ中止・Slack通知

  - name: Deploy to Staging
    trigger: mainプッシュ
    jobs:
      - DBマイグレーション（後方互換）
      - アプリデプロイ
      - スモークテスト
    goal_duration: 5分以内
    on_failure: Slack通知・手動対応

  - name: Deploy to Production
    trigger: タグプッシュ（v*）or 手動承認
    jobs:
      - DBマイグレーション（後方互換）
      - アプリデプロイ（Blue-Green or Canary）
      - デプロイ後ヘルスチェック（エラー率・レイテンシ確認）
      - リリースノート公開
    goal_duration: 10分以内
    on_failure: 自動ロールバック or Slack通知・手動ロールバック

# リリース手順書テンプレート
release:
  pre_checks:
    - stagingで動作確認済みか
    - DBマイグレーションの後方互換性を確認したか
    - ロールバック手順を確認したか
    - 監視ダッシュボードを開いているか
    - 対応可能な時間帯か（金曜夕方・深夜でないか）

  steps:
    - gitタグを打つ: git tag v1.2.3 && git push origin v1.2.3
    - CIパイプラインの完了を確認
    - デプロイ後5分間、エラー率・レイテンシを監視
    - 問題なければSlackにリリース通知

  post_checks:
    - エラー率が基準値以内か
    - レイテンシが基準値以内か
    - 主要機能のスモークテスト通過

  rollback:
    - トリガー条件: エラー率5%超 or レイテンシ2倍超 or 重大バグ
    - In-place: 前バージョンを再デプロイ
    - Blue-Green: ロードバランサーを旧環境に切り替え
    - DB: 前方互換マイグレーションで対応（巻き戻しは原則しない）
    - 完了後: 原因調査・ポストモーテム作成

チェックリスト

  • CIがPR単位で自動実行されている
  • mainブランチ保護ルール(CI必須通過)が有効
  • CIの総所要時間が10分以内
  • dev/staging/productionの環境分離が明確
  • シークレットがCI/CDプラットフォームのシークレット機構で管理されている
  • コードやログにシークレットが平文で出ない
  • DBマイグレーション→新コードデプロイの順序が固定されている
  • ロールバック手順書が存在し、stagingで検証済み
  • デプロイ後のエラー率・レイテンシ確認フローがある
  • デプロイ通知がチームに届く
  • gitタグ・CHANGELOGのルールが決まっている
  • 金曜夕方・深夜・連休前のデプロイを避けるルールがある

アンチパターン

  • 手動デプロイ依存 — 手順が属人化し、担当者不在時に詰まる。スクリプト化・自動化必須
  • ロールバック手順の未検証 — 「手順はある」が実際に動かない状態。定期的にstagingで訓練する
  • 「急ぎだから」テストスキップ — 一度許容すると常態化する。スキップするなら理由をPRに記録する
  • stagingと本番の構成乖離 — stagingで通ったのに本番で壊れる原因。IaCで設定を同期する
  • デプロイ後に確認せず帰る — エラーに気づくのが翌朝になる。最低5分は監視してから離席する
  • 過剰なインフラ — 個人・小規模プロジェクトにKubernetesは不要。PaaSの活用で十分

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割担当タスク例
司令塔(メインモデル)デプロイ戦略・環境構成の判断デプロイ戦略選定、環境構成レビュー、ロールバック方針の確定
Opus相当パイプラインの複雑な問題調査フレーキーテストの根本原因分析、複雑なCI設定の構造調査
Sonnet相当ワークフローファイルの実装・改善GitHub Actions / GitLab CI YAMLの作成・修正、デプロイスクリプト実装
Haiku相当CI失敗ログの一次解析エラーログの要約、定型チェックの実行、通知メッセージ生成

関連スキル

  • [[orchestration]] — マルチモデル委譲の共通原則
  • [[testing]] — CIで自動実行するテスト設計
  • [[security]] — シークレット管理・デプロイ時のセキュリティ
  • [[database-design]] — マイグレーション設計・後方互換性
  • [[monitoring-operations]] — デプロイ後の観測・アラート設計
  • [[git-workflow]] — ブランチ戦略・タグ運用
  • [[solo-development]] — 個人開発でのCI/CD現実解

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.