cicd について
CI/CD パイプラインやデプロイ方法を設計するチーム向けのリファレンススキルです。パイプラインの原則、デプロイ戦略、環境間の昇格、よくあるアンチパターンを扱います。
主な機能
- 01CI・デリバリー・デプロイの違い
- 02パイプライン設計原則
- 03デプロイ戦略の比較
- 04環境昇格の指針
- 05アンチパターンと対策
活用シーン
- 01リリース方式の選定
- 02迅速なフィードバックのための検査設計
- 03環境間での成果物の昇格
- 04パイプラインの安全性と信頼性の点検
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ krzysztofsurdy/ code-virtuoso --skill cicdインストール後、Claude Code で/cicdを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/deployment-strategies.mdenvironment-management.mdpipeline-design.md詳細
CI/CD パイプラインのパターンとデプロイ戦略
継続的インテグレーション、継続的デリバリー、継続的デプロイメントは、自動化の取り組みを段階的に高めたものです。それぞれが前の段階を土台とし、コード変更からユーザーが利用できるようになるまでの手作業をさらに減らします。
CI vs CD vs CD
| プラクティス | 自動化する内容 | 次の段階へのゲート |
|---|---|---|
| 継続的インテグレーション | コミットごとのコードのマージ、ビルド、テスト | マージ前に自動テストに合格する必要があります |
| 継続的デリバリー | 成果物のパッケージ化と環境間での昇格 | 本番環境へのデプロイ前に手動承認が必要です |
| 継続的デプロイメント | コミットから本番環境までの全工程を、手動の手順なしで実行します | 自動化された品質ゲートが人による承認に取って代わります |
継続的インテグレーションは基盤です。信頼性が高く高速なインテグレーションがなければ、デリバリーもデプロイメントも持続できません。まずはそこから始めましょう。
パイプライン設計の原則
優れたパイプラインは、開発者に迅速で信頼できるフィードバックを提供し、不具合のあるコードがユーザーに届かないようにします。
| 原則 | 意味 |
|---|---|
| 迅速なフィードバック | 最も低コストで高速なチェックを先に実行します。リンティングや単体テストを、インテグレーションテストやビルドより先に行います |
| 早期の失敗検出 | 最初の失敗時点でパイプラインを停止します。上流のチェックに失敗した場合、後続の段階に時間を費やしません |
| 再現性 | 同じ入力を使ったパイプラインの実行では、常に同じ出力が生成される必要があります。依存関係を固定し、不変のベースイメージを使用します |
| 冪等性 | パイプラインの段階を再実行しても安全で、同じ結果が得られるようにします |
| 分離 | パイプラインの実行ごとにクリーンな環境を使用し、実行間で状態を共有しません |
| デフォルトでのセキュリティ | シークレットは実行時に注入し、ソースに保存しません。脆弱性を早期にスキャンします |
デプロイ戦略の概要
| 戦略 | ダウンタイム | ロールバックの速さ | インフラストラクチャのコスト | 複雑さ | 最適な用途 |
|---|---|---|---|---|---|
| ブルーグリーン | なし | 即時(トラフィックの切り替え) | 本番環境の2倍 | 低 | 大規模リリース、リスクを避けるチーム |
| カナリア | なし | 高速(トラフィックを元に戻す) | 1倍+小規模なカナリア枠 | 中 | データ重視のチーム、トラフィックの多いサービス |
| ローリング | なし(サージを設定した場合) | 低速(ロールアウトを逆順に実行) | 1倍(既存環境を再利用) | 低 | ステートレスなサービス、小規模な変更を頻繁に行う場合 |
| 再作成 | あり(短時間) | 低速(全体を再デプロイ) | 1倍 | 最小 | 開発/ステージング環境、2つのバージョンを同時に実行できないステートフルなアプリ |
| フィーチャーフラグ | なし | 即時(無効に切り替え) | 1倍 | 中 | 段階的なロールアウト、A/B テスト、トランクベース開発 |
あらゆる状況に適した単一の戦略はありません。たとえば、新機能を誰に見せるか制御するため、フィーチャーフラグを使ったカナリアリリースを組み合わせるなど、多くのチームが複数の戦略を併用しています。
環境管理の概要
一般的な昇格経路では、成果物を本番環境に近い環境へと順次移動します。
dev -> staging -> production
原則:
- 成果物の不変性 - 一度だけビルドし、すべての環境に同じ成果物をデプロイします。環境ごとに再ビルドしてはいけません。
- 設定の分離 - 環境固有の値(データベース URL、API キー、フィーチャートグル)は、成果物の外部に置きます。
- 同等性 - ステージング環境は、インフラストラクチャ、データの形状、規模において、できる限り本番環境を再現する必要があります。
- エフェメラル環境 - テストやレビュー用に、プルリクエストごとに分離された環境を起動し、PR がクローズされたら破棄します。
クイックリファレンス:パイプラインのアンチパターン
| アンチパターン | 問題 | 解決策 |
|---|---|---|
| 環境ごとに成果物を再ビルドする | ステージング環境と本番環境でバイナリが異なる | 一度だけビルドし、同じ成果物を昇格させる |
| 長時間実行されるモノリシックなパイプライン | フィードバックが遅く、開発者がコンテキストを切り替える必要がある | ステージを並列化し、目的を絞ったパイプラインに分割する |
| ソース管理にシークレットを保存する | 認証情報の漏えい、コンプライアンス違反 | シークレットマネージャーを使用し、実行時に注入する |
| 環境を手動でセットアップする | 設定のずれ、「自分の環境では動く」問題 | Infrastructure as Code とコンテナ化されたビルドを使用する |
| ロールバック計画がない | デプロイに失敗した場合、停止時間が長引く | ロールバックを自動化し、定期的にテストする |
| ステージングを省略する | 本番環境固有のバグが発見されるのが遅すぎる | 少なくとも 1 つの本番前環境を必ず経由して昇格させる |
参考ファイル
| 参考資料 | 内容 |
|---|---|
| パイプライン設計 | パイプラインのステージ、並列化、キャッシュ、モノレポのパターン、複数形式の例を含むシークレット管理 |
| デプロイ戦略 | ブルーグリーン、カナリア、ローリングデプロイ、フィーチャーフラグ、ダウンタイムゼロの移行、ロールバック戦略 |
| 環境管理 | 環境の昇格、Infrastructure as Code、一時的な環境、成果物のバージョン管理、ヘルスチェック |
他のスキルとの連携
| 状況 | 推奨スキル |
|---|---|
| デプロイの監視とオブザーバビリティ | microservices |
| パイプラインでのセキュリティスキャン | security |
| CI パイプラインのテスト戦略 | testing |
| デプロイ時の API バージョン管理 | api-design |
コメント
Markdown 対応