初級では CI/CD を「変更を自動でテストして届ける流れ作業」と捉えました。中級では、その流れ＝パイプライン の段取りと、なぜ小さく頻繁に出すほど安全なのか を見ます。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
CI/CD の本体は パイプライン——ソース取得→ビルド→テスト→デプロイと 自動でつながった段取り です。各段階を ステージ と呼びます。
アニメーション『CI/CDパイプラインの流れ』を開く
登場人物メモ:
- ※1 トリガ — パイプラインを起動させるイベント（push・プルリクエストなど）
- ※2 アーティファクト（成果物） — ビルドで出来た配布物。同じ物を各環境へ配る
- ※3 ロールバック — 問題が出たとき、1つ前の正常な状態へ戻すこと
この部分をもっと深く（上級）
上級のCI/CDでは、パイプラインを画面でポチポチ組む設定ではなく、リポジトリに置いたコード（パイプライン・アズ・コード）として書きます。これはIaCと同じ発想の応用です。
- バージョン管理される — パイプラインの定義がGitの履歴に載り、いつ誰が段取りを変えたか追える
- レビューできる — 「テストを一段飛ばす」ような変更も、コード差分として事前に見える
- 再現できる — 同じ定義から同じ流れが再生される。担当者の手順の記憶に依存しない
アニメーション『CI/CDパイプラインの流れ』を開く
登場人物メモ:
- ※1 パイプライン・アズ・コード — CI/CDの段取りを設定ファイルとして記述し、履歴管理する書き方
- ※2 昇格（プロモート） — 同じ成果物を、下の環境から上の環境へ順に進めること
- ※3 出所（provenance） — その成果物が「どのソースから・どの手順で作られたか」の証明
やさしく言うと（初級）
CI/CD は、コードの変更を 自動でテストして届ける 流れ作業（※1 パイプライン）です。名前は2つの頭文字からできています。
- CI（継続的インテグレーション） — 変更のたびに 自動でビルド・テスト し、壊れをすぐ見つける
- CD（継続的デリバリー／デプロイ） — テストを通ったものを 自動で本番へ配る
工場のベルトコンベアを思い浮かべてください。部品（変更）を載せると、検査（テスト）を通り、合格したものだけが出荷（本番）される——それを人手なしで回すイメージです。
登場人物メモ:
- ※1 パイプライン — 取得→ビルド→テスト→配布と、自動でつながった一連の段取り
- ※2 ビルド — 書いたコードを、実際に動く形に組み立てる工程
仕事の流れ
- push などの トリガ でパイプラインが起動する
- ビルド で成果物（アーティファクト）を作る
- テスト を通し、失敗したらそこで止めて差し戻す
- 通れば 環境 を段階的に進めて配る（開発→ステージング→本番）
同じ成果物を各環境へ運ぶのがコツです。環境ごとに作り直さないので、「本番だけ動かない」を防げます。
下の図は、push を引き金にビルド・テストが走り、成果物がレジストリ経由で本番へ届くまでを1手ずつ追ったものです。
アニメーション『CI/CDパイプラインの走行（push→build→test→deploy）』を開く
- 開発者 — 変更を push する人。ここから先は基本すべて自動で流れる
- CI — push を引き金に走る自動化係。ビルドとテストを順に実行する
- レジストリ — ビルドした成果物（イメージ）を保管する棚。各環境はここから同じ物を受け取る
- 本番 — 利用者に届く環境。テストを通った成果物だけがここへ配られる
0 / 6
やさしく言うと（初級）
- 開発者がコードの変更を送る（これが引き金）
- 自動で ビルド（※2 動く形に組み立て）される
- 自動で テスト され、壊れていないか検査される
- 通れば 自動で本番へ配られる（失敗したら止まって差し戻し）
大事なのは、この一連が 人の操作なしで一気に流れる こと。だから速く、ミスが減ります。
設計の勘所
- 環境の段階 — いきなり本番ではなく、本番同等の ステージング で最終確認してから出す
- ロールバック（※3）— 問題が出たら すぐ前の版へ戻せる 備えを用意しておく
- 小さく頻繁に — 1回の差分を小さく保つと、壊れても原因の切り分けと戻しが容易
- 失敗は止める — テストが赤なら先へ進めない設定にし、壊れを本番の手前で堰き止める
なぜ小さく頻繁が安全か。大きな変更をまとめて出すと、失敗時に どの変更が原因か分からず、戻すと他の正常な変更まで巻き添えにします。小さければ、その1つを戻すだけで済みます。
この部分をもっと深く（上級）
いきなり全利用者へ出すのは危険です。段階を踏み、切り替え方そのものを選びます。
- 環境の昇格 — 開発→ステージング→本番と、同じ成果物を順に進める。各段でテストや承認を挟む
- ローリング — サーバを少しずつ新版へ入れ替える。落とさず進むが、新旧が一時混在する
- ブルーグリーン — 新版の環境（緑）を丸ごと用意し、入口を一斉に切り替える。問題が出たら入口を戻すだけで即ロールバック
- カナリア — 新版をまず一部の利用者にだけ配り、指標を見て問題なければ徐々に広げる。異常を小さな範囲で早く掴める
- ロールバック — どの戦略でも「すぐ前の版へ戻せる」備えを前提にする。Kubernetesなどは版を記録し、戻す操作を一手で行える
やさしく言うと（初級）
- 壊れをすぐ検知 — 変更した直後にテストが走るので、原因がすぐ分かる
- 手作業のミスが減る — 配る手順を人がやらないので、打ち間違いが起きない
- 待ち時間が消える — 「担当者が手で上げるのを待つ」がなくなる
小さな変更をこまめに流せるので、問題が起きても原因が絞りやすい のも利点です。
⚠️ うまくいかないとき
- テスト不足 — 検査が薄いと、壊れが本番へ通り抜ける
- パイプラインが遅い — 検査に時間がかかると、開発全体が詰まる
- 環境差 — 本番とステージングの構成がずれると、通ったのに本番で落ちる
- 戻せない設計 — ロールバック手段がないと、障害時に復旧が長引く
この部分をもっと深く（上級）
- 環境ごとの作り直し — 同一成果物を昇格せず作り直すと、テストで確かめた物と本番の物が食い違う
- キャッシュの取り違え — 鍵の設計が甘いと古い依存を掴み、「手元では直ったのにCIで再発」する
- 戻せないデプロイ — ロールバック手段のない切り替えは、障害時に復旧が長引く
- 秘密のログ流出 — マスキング漏れや冗長なデバッグ出力で、鍵が履歴に残ってしまう
やさしく言うと（初級）
- テストが甘い — 検査が薄いと、壊れたまま本番へ通ってしまう
- テストが遅い — 検査に時間がかかると、流れ全体が詰まる
- 失敗を無視 — 赤（失敗）を放置すると、自動化の意味が消える
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 「小さく頻繁にリリースする」ほうが安全とされる主な理由は？
問2. CI/CDのパイプラインを起動する「トリガ」の例として正しいのは？
問3. パイプラインを構成するビルドやテストなどの各段階の呼び方はどれ？
問4. いきなり本番へ出さず、本番同等の環境で最終確認してから配るための段階はどれ？
問5. 「ロールバック」の説明として正しいのは？
問6. 同じ成果物を各環境へ配る（作り直さない）ことの利点として正しいのは？
問7. ソース取得→ビルド→テスト→デプロイと自動でつながった一連の段取り全体を、カタカナで何と呼びますか。
問8. ビルドで出来上がり、各環境へ同じ物を配る「配布物（成果物）」をカタカナで何と呼びますか。