CI/CDとリリース

第28講 / 全32講読了目安約55分

このページで学ぶこと

CI、Continuous Delivery、Continuous Deploymentの違い
変更からテスト・ビルド・検証・本番公開までのパイプライン
環境、シークレット、承認、同時実行、成果物の管理
デプロイ方式、データベース変更、フィーチャーフラグ、ロールバックの注意
PMが公開頻度・責任・失敗時対応を設計する方法

まず全体像

CI/CDは、コードを書いた担当者だけが知る手順を減らし、変更を繰り返し検査・公開できる仕組みと実践です。

flowchart LR
    C[変更・コミット] --> P[Pull Request]
    P --> CI[CI<br/>静的解析・テスト・ビルド]
    CI --> V[検証環境]
    V --> A[承認]
    A --> D[本番デプロイ]
    D --> M[監視・確認]
    M --> F[フィードバック]
    F --> C

自動化の目的は、単に作業時間を短縮することではありません。

同じ手順を再現する
問題を早く発見する
変更と公開版を追跡する
人為的な作業漏れを減らす
小さな変更を安全に届ける
問題時に戻せるようにする

ことです。

CIとは

CI（Continuous Integration、継続的インテグレーション）は、開発者が変更を頻繁に共有ブランチへ統合し、そのたびに自動ビルド・テスト等を行う実践です。

flowchart TD
    A[担当者Aの変更] --> M[共有ブランチへ統合]
    B[担当者Bの変更] --> M
    M --> T[自動ビルド・テスト]
    T --> R{問題}
    R -->|あり| F[早く修正]
    R -->|なし| N[次の小さな変更]

変更を数週間ためて最後に統合すると、

差分が大きい
問題原因を特定しにくい
類似不具合を増やす
公開時期を予測しにくい

状態になります。

小さく頻繁に統合し、短いフィードバックを得ることがCIの中心です。

CIサービスを導入しただけでCIになるわけではありません。

大きなブランチを長期間放置し、最後に自動テストを実行しても、継続的な統合の効果は小さくなります。

CIで行う処理

案件に応じて次を自動化します。

コード整形・規約
型チェック
単体テスト
コンポーネントテスト
ビルド
リンクチェック
アクセシビリティ自動検査
依存脆弱性検査
秘密情報検査
ライセンス確認
E2Eテスト
プレビュー作成
成果物生成

すべてを一つのジョブへ入れる必要はありません。

高速な必須チェックを先に実行し、時間のかかるテストを並列・段階実行するなど、開発速度と信頼性を調整します。

Continuous DeliveryとContinuous Deployment

日本語ではどちらも継続的デリバリーと呼ばれることがありますが、一般に次のように区別されます。

Continuous Delivery

変更を、本番へいつでも安全に公開できる状態まで自動で準備します。

本番公開は人間の承認・操作で行う場合があります。

Continuous Deployment

自動テスト・条件を通過した変更を、人間の都度承認なしで本番へ自動公開します。

flowchart LR
    C[変更] --> T[テスト・ビルド]
    T --> S[公開可能な成果物]
    S -->|人間が承認| CD1[Continuous Delivery]
    S -->|自動で本番へ| CD2[Continuous Deployment]

どちらが優れているかではありません。

公開頻度
リスク
規制・承認
監視
自動テスト
切戻し
組織の信頼性

に応じて選びます。

企業サイトの文言更新でも、CMS公開は編集者承認、本体コードはPull Request承認等、経路ごとに方式が異なります。

パイプライン

パイプラインは、変更を検査・公開する一連の処理です。

flowchart LR
    S[ソース取得] --> I[依存取得]
    I --> L[静的解析]
    L --> T[テスト]
    T --> B[ビルド]
    B --> P[プレビュー・検証]
    P --> A[承認]
    A --> D[本番デプロイ]
    D --> K[スモークテスト]

各段階について決めます。

開始条件
入力
実行環境
成功条件
失敗通知
再実行
タイムアウト
成果物
承認
ログ保存
費用

パイプライン自体もソフトウェアであり、更新・レビュー・権限管理が必要です。

トリガー

CI/CDを開始するきっかけです。

Pull Request作成・更新
ブランチへのpush
タグ作成
CMS Webhook
手動実行
定期実行
外部API
他ワークフロー完了

同じ変更で複数回ビルドが起きると、費用・待ち時間が増えます。

CMSを短時間に連続更新した場合、ビルドをまとめる・古い実行を中止する等を検討します。

実行環境

CI/CDの処理を実行するマシンをランナー等と呼びます。

サービス提供のランナー

GitHub等が用意した環境で実行します。

準備が少ない
実行ごとに新しい環境を使いやすい
対応OS・性能・ネットワークに制約
利用時間・容量に課金

セルフホストランナー

自社・クライアント環境のマシンで実行します。

社内ネットワーク・特殊環境へ接続できる
性能・ソフトウェアを管理できる
OS更新、隔離、秘密情報、停止、スケールの管理が必要
信頼できないコードを実行するリスク

採用理由と保守担当を明確にします。

成果物

ビルドで作った公開用ファイル、アプリ、コンテナ等を成果物（artifact）として保存します。

利点：

テストしたものと同じ成果物を本番へ出す
再ビルドによる差を避ける
以前の版へ戻しやすい
版・ハッシュを追跡できる
納品物を特定できる

保存期間、容量、アクセス権、個人情報・秘密情報が含まれないかを確認します。

「本番公開のたびに別環境で再ビルド」すると、依存パッケージや外部APIの変化で、検証時と異なる成果物になる場合があります。

環境

一般に次の環境を使い分けます。

開発
Pull Requestプレビュー
結合・検証
ステージング
本番

環境ごとに次が異なります。

ドメイン
API
CMS
データ
認証
外部メール・決済
計測
シークレット
性能
CDN・キャッシュ

ステージングがあるだけで、本番と同条件とは限りません。

何を検証でき、何が本番でしか確認できないかを一覧化します。

環境保護と承認

GitHub Actions等では、本番環境に対して、

指定ブランチ・タグだけ許可
必須レビュー
待機時間
カスタム保護条件
環境別シークレット

を設定できます。

flowchart TD
    W[本番デプロイジョブ] --> B{許可ブランチか}
    B -->|いいえ| X[停止]
    B -->|はい| T{必須テスト成功}
    T -->|いいえ| X
    T -->|はい| A{承認}
    A -->|却下| X
    A -->|承認| D[本番へデプロイ]

承認者は、差分・テスト結果・公開時間・影響・切戻しを確認できる必要があります。

承認ボタンを形式的に押すだけにしません。

シークレット

CI/CDは本番環境へアクセスするため、強い権限を持つことがあります。

管理事項

リポジトリ・環境単位の保存
開発・本番の分離
必要なジョブだけ参照
ログへ出力しない
Pull Requestからの利用制限
有効期限・ローテーション
クラウド側で最小権限
長期キーより短期的な認証
退場・漏えい時の失効
外部Actionへ渡る情報

第三者のGitHub Actionは、実行時にソースやトークンへアクセスできる場合があります。

提供元・バージョン固定・権限を確認します。

依存パッケージの再現性

同じソースから同じ成果物を作れるようにします。

Node.js等のバージョン
パッケージマネージャー
ロックファイル
OS
ビルドコマンド
環境変数
タイムゾーン
外部API
画像変換

を固定・記録します。

依存パッケージを毎回最新へ解決すると、ソースを変更していないのにビルドが壊れる場合があります。

一方、永遠に固定すると脆弱性・保守終了へ追従できません。

計画的な更新と回帰テストを組み合わせます。

プレビュー環境

Pull Requestごとに一時URLを作ると、コードを読めない関係者も変更を確認できます。

確認事項

アクセス制限
noindex
本番個人情報を使わない
テスト用API・CMS
メール・決済を本番へ送らない
URLの有効期限
外部共有
デザイン・アクセシビリティ確認
削除

noindexは秘密情報を守るアクセス制御ではありません。

機密性が必要なら認証・ネットワーク制限を使います。

デプロイ方式

全置換

新しい成果物一式へ切り替えます。

静的ホスティングでは一般的で、成果物単位の切替なら整合を保ちやすくなります。

ローリング

複数サーバーを順番に新バージョンへ更新します。

停止時間を抑えられますが、新旧版が一時混在します。

Blue-Green

旧環境と新環境を並行用意し、接続先を切り替えます。

切戻しやすい一方、二環境の費用とデータ整合が必要です。

Canary

一部の利用者・トラフィックだけ新バージョンへ流し、問題を確認して拡大します。

監視・振り分け・比較が必要です。

Feature Flag

コードは公開しても、機能を設定で有効化します。

公開と機能提供を分離できますが、古いフラグ、条件分岐、テスト組合せが増えます。

案件規模・リスクに合う方式を選びます。

同時実行と順序

同じ環境へ複数デプロイが同時に走ると、古い変更が後から上書きする等の問題が起きます。

本番デプロイを一つずつ実行
新しい実行で古い待機処理を取消
CMSビルドをまとめる
環境ごとにロック
公開順序をキュー管理

を設定します。

緊急修正が通常リリース待ちで止まる場合の優先手順も決めます。

データベース・CMSスキーマ変更

コードだけのデプロイより注意が必要です。

問題例

新コードが新DB列を要求する
旧コードが新構造で動かない
データ変換に時間がかかる
変更を戻せない
CMS項目削除でフロントが失敗
複数サービスの公開順序がある

安全な考え方

互換期間を作る
先に追加し、利用開始後に旧項目を削除
バックアップ
移行時間測定
ロールフォワードも検討
公開順序
書き込み停止
監視
手動復旧

「コードを戻せる」ことと「データを戻せる」ことを分けます。

ロールバックとロールフォワード

ロールバック

以前の版へ戻します。

適する例：

静的ファイル
後方互換性のある変更
以前の成果物が保存されている

ロールフォワード

問題を修正した新しい版を追加公開します。

適する例：

データ変更を戻せない
外部状態が進んでいる
以前の版が新データと互換しない
小さな修正をすぐ出せる

flowchart TD
    I[問題発生] --> A{旧版へ安全に戻せるか}
    A -->|はい| R[ロールバック]
    A -->|いいえ| F[修正版をロールフォワード]
    R --> M[監視・原因分析]
    F --> M

リリース前に判断条件を決めます。

「問題があれば戻します」だけでは、実際に何分で誰が何を戻すか不明です。

スモークテスト

デプロイ直後に、最重要機能が動くか短時間で確認します。

トップ・主要ページ
CSS・画像
ログイン
検索
フォーム
API
CMS公開
監視・ログ
リダイレクト
計測

自動化できるものと、本番で人間が確認するものを分けます。

スモークテスト失敗時に、自動停止・切戻し・判断者連絡のどれを行うか決めます。

リリースノート

変更を利用者・運用・関係者へ伝えるための記録です。

内部向け

変更内容
影響範囲
既知制約
データ・設定変更
監視ポイント
切戻し
問い合わせ先

利用者向け

新機能
操作変更
停止時間
必要な対応
問い合わせ

すべての技術コミットを並べるのではなく、相手に必要な情報へ変換します。

公開カレンダー

複数案件・施策では、公開日だけでなく次を管理します。

コード凍結
コンテンツ確定
受入
診断・再確認
DNS・外部申請
公開承認
メンテナンス
監視強化
関係者告知
旧環境停止

他部署のキャンペーン、決算、広告、システムメンテナンスとの競合を確認します。

実案件ではどう考えるか

ヘッドレスCMS＋SSG

flowchart LR
    C[CMS公開] --> W[Webhook]
    W --> B[ビルド]
    B --> T[自動テスト]
    T --> D[静的ホスティングへ配置]
    D --> P[キャッシュ更新・確認]

連続更新時のビルド
失敗通知
旧版維持
予約公開
緊急公開
検索インデックス

を設計します。

毎月の定期リリース

変更を月末へためすぎると、差分・不具合・切り分けが大きくなります。

本番公開は月次でも、CI・検証環境への統合は小さく頻繁に行います。

複数ベンダー

フロント、API、インフラで別パイプラインの場合、

API互換性
公開順序
バージョン
連絡
共通ステージング
ロールバック責任

を統合リリース計画にします。

PMチェックリスト

よくある誤解・失敗

「GitHub Actionsを使えばCI/CDを導入したことになる」

ツールだけではなく、小さな統合、自動検査、常に公開可能な状態、監視・改善の実践が必要です。

「自動化すれば人間の承認は不要」

高リスク・規制・業務判断では承認が必要です。逆に形式的な承認だけなら、条件・自動検査を改善します。

「ステージングでテストしたコードを本番で再ビルドしても同じ」

依存物・環境・外部データにより成果物が変わる場合があります。検査済み成果物を昇格させる方法を検討します。

「ロールバックは一つ前のデプロイを選ぶだけ」

DB、CMS、外部API、送信済みデータ、新旧互換性によって戻せない場合があります。

「自動デプロイなら公開担当は不要」

失敗・監視・事業判断・外部連絡・インシデント対応の責任者は必要です。

理解度チェック

Q1. CIの中心的な考え方は何ですか。

回答と解説

変更を小さく頻繁に共有ブランチへ統合し、そのたびに自動ビルド・テスト等で早いフィードバックを得ることです。

Q2. Continuous DeliveryとContinuous Deploymentの違いは何ですか。

回答と解説

Deliveryは本番へいつでも公開可能な状態まで継続的に準備し、本番公開に人間の判断を残せます。Deploymentは条件を通った変更を自動で本番へ公開します。

Q3. CI/CDのシークレット管理で確認することを挙げてください。

回答と解説

環境分離、最小権限、ログ非表示、Pull Requestからの利用、更新・失効、第三者Actionへの露出、クラウド側権限等です。

Q4. DB変更を伴うデプロイで、単純なロールバックが難しい理由は何ですか。

回答と解説

新しいデータ構造や変換済みデータが旧コードと互換しない、処理済みデータを戻せない、複数サービスの順序があるためです。

Q5. 本番デプロイ直後に行うスモークテストの目的は何ですか。

回答と解説

最重要ページ・機能・外部連携が本番条件で最低限動くかを短時間で確認し、重大問題を早く検知して切戻し等を判断するためです。

参考資料

サイボウズ「CI/CD 2021」
https://speakerdeck.com/cybozuinsideout/cd-2021
大きな差分を最後に統合する問題と、CI・継続的デリバリーの基礎を学ぶ参考資料。
GitHub Docs「Deploying with GitHub Actions」
https://docs.github.com/actions/deployment/about-deployments/deploying-with-github-actions
environment、concurrency、保護ルールを使うデプロイの公式資料。
GitHub Docs「Deployments and environments」
https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
必須承認、待機、許可ブランチ等のデプロイ保護を確認する公式資料。
Google SRE Book「Release Engineering」
https://sre.google/sre-book/release-engineering/
再現可能・自動化・監査可能なリリースの考え方。