CI/CD
GitHub Actions でビルド・テスト・デプロイを自動化し、リリース頻度を高める
よくあるシナリオ:リリース恐怖症の悪循環
SaaSクライアントで月1回のリリースが「全社的な大イベント」。リリース当日は開発・QA・インフラ全員が待機。毎回3〜4件のバグが出て深夜対応に。「リリースを止めよう」という声が出るが、止めるとバックログが膨れ上がり、次回リリースがさらに大規模に。
- リリースのたびに深夜対応が発生する消耗
- 変更差分が大きすぎてバグの原因特定に時間がかかる
- コード完成からリリースまで2〜3週間かかる
- 「金曜リリース禁止」文化が根付き開発速度が低下
CI/CD パイプライン
CI/CD パイプライン
プッシュのたびに自動検証。バグを早期発見。
いつでも本番リリースできる状態を維持。
核心概念を押さえる
コードをプッシュするたびにビルド・テストを自動実行。問題を小さいうちに発見。「自分のマシンでは動く」問題を解消。
例:PRをmainにマージするたびに自動でテスト600件が走り、失敗したらマージブロック
テスト済みコードが常にデプロイ可能な状態に保たれる。本番へのリリースタイミングはビジネス側がコントロール。
例:mainブランチのコードは常に本番品質。リリースはボタン1つで即実施可能。
Googleが発見した4指標:デプロイ頻度・リードタイム・変更失敗率・MTTR。エリートチームは全指標でハイパフォーマー。
例:エリートチーム: デプロイ1日複数回、リードタイム<1時間、失敗率<5%
現行(Blue)と新版(Green)を同時稼働させ、一瞬でトラフィックを切り替え。問題があれば即ロールバック。
例:新バージョンをGreenで起動→ヘルスチェックOK→1秒でBlue→Greenに切り替え
新バージョンを5〜10%のユーザーに先行公開。問題なければ段階的に100%へ。問題があれば残り90%に影響しない。
例:新機能を5%のユーザーに公開→エラー率正常→24時間後に50%→48時間後に100%
デプロイ後のスモークテストが失敗、またはエラー率が閾値を超えたら自動で前バージョンに戻す仕組み。
例:デプロイ後5分以内にエラー率が1%超過→自動的に前バージョンに切り戻し
デプロイ戦略の比較
本番環境(Blue)と同一の新環境(Green)を用意し、ルーティングを一瞬で切り替え
新バージョンを全体の5〜10%のユーザーに先行公開し、問題なければ段階的に拡大
サーバーを1台ずつ順番に更新。古いバージョンと新バージョンが一時共存する
AI で SRE の仕事はどう変わるか
- パイプライン設定(YAML)を一から手書き
- Flaky Test(不安定なテスト)の原因を手動調査
- デプロイリスクを経験則で判断
- 障害後のロールバック判断を人間が手動実施
- 「このアプリをデプロイするパイプラインを作って」でYAML自動生成(GitHub Copilot)
- Flaky Testを自動検出し修正方法を提案(Trunk.io)
- 変更内容を解析してデプロイリスクスコアを算出(Harness AI)
- 異常検知→自動ロールバック→Slack通知まで自律実行(Argo Rollouts AI)
- デプロイ戦略(Blue-Green/カナリア)の設計判断
- セキュリティ要件・コンプライアンスの確認
- パイプラインアーキテクチャの改善方針決定
- 新しいリリース戦略のビジネス優先度の評価
主なツール:GitHub Copilot、Harness AI、Trunk.io、LinearB、Argo Rollouts
この先の見通し:2027年にはAIが変更内容を理解し「このPRは本番への影響リスクが高い、段階的リリースを推奨」と自動判断。デプロイの意思決定の大半をAIが担い、人間は「リリースするか否か」の最終承認に特化する時代へ。
導入による効果の目安(業界の一般的な傾向)
- デプロイ頻度向上
- 10倍
- 月1→日次への転換
- 変更失敗率低減
- -50%
- 自動テストの効果
- リードタイム短縮
- -80%
- コード完成→本番の時間
- ロールバック対応
- 即時
- 問題発生から復旧まで