agentsclimarketplace

Cicd deployment

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

システム開発・個人開発の全工程(企画〜設計〜実装〜運用〜マネタイズ)をカバーするClaude Code用スキル集

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.

What its author says it does

Copied from the file, not written here

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

SKILL.md

9.5 KB, 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現実解

Keep looking

Skills are one crate of 328,083. 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.