初級では CI/CD を「変更を自動でテストして届ける流れ作業」と捉えました。中級では、その流れ＝パイプライン の段取りと、なぜ小さく頻繁に出すほど安全なのか を見ます。
中級の解説は準備中のため、中級の内容を表示しています。
概要 — まず全体をつかむ
詳細 — 1段階ずつ追う
これは何をする係？
CI/CD の本体は パイプライン——ソース取得→ビルド→テスト→デプロイと 自動でつながった段取り です。各段階を ステージ と呼びます。
アニメーション『CI/CDパイプラインの流れ』を開く
登場人物メモ:
- ※1 トリガ — パイプラインを起動させるイベント（push・プルリクエストなど）
- ※2 アーティファクト（成果物） — ビルドで出来た配布物。同じ物を各環境へ配る
- ※3 ロールバック — 問題が出たとき、1つ前の正常な状態へ戻すこと
仕事の流れ
- push などの トリガ でパイプラインが起動する
- ビルド で成果物（アーティファクト）を作る
- テスト を通し、失敗したらそこで止めて差し戻す
- 通れば 環境 を段階的に進めて配る（開発→ステージング→本番）
同じ成果物を各環境へ運ぶのがコツです。環境ごとに作り直さないので、「本番だけ動かない」を防げます。
下の図は、push を引き金にビルド・テストが走り、成果物がレジストリ経由で本番へ届くまでを1手ずつ追ったものです。
アニメーション『CI/CDパイプラインの走行（push→build→test→deploy）』を開く
- 開発者 — 変更を push する人。ここから先は基本すべて自動で流れる
- CI — push を引き金に走る自動化係。ビルドとテストを順に実行する
- レジストリ — ビルドした成果物（イメージ）を保管する棚。各環境はここから同じ物を受け取る
- 本番 — 利用者に届く環境。テストを通った成果物だけがここへ配られる
0 / 6
設計の勘所
- 環境の段階 — いきなり本番ではなく、本番同等の ステージング で最終確認してから出す
- ロールバック（※3）— 問題が出たら すぐ前の版へ戻せる 備えを用意しておく
- 小さく頻繁に — 1回の差分を小さく保つと、壊れても原因の切り分けと戻しが容易
- 失敗は止める — テストが赤なら先へ進めない設定にし、壊れを本番の手前で堰き止める
なぜ小さく頻繁が安全か。大きな変更をまとめて出すと、失敗時に どの変更が原因か分からず、戻すと他の正常な変更まで巻き添えにします。小さければ、その1つを戻すだけで済みます。
⚠️ うまくいかないとき
- テスト不足 — 検査が薄いと、壊れが本番へ通り抜ける
- パイプラインが遅い — 検査に時間がかかると、開発全体が詰まる
- 環境差 — 本番とステージングの構成がずれると、通ったのに本番で落ちる
- 戻せない設計 — ロールバック手段がないと、障害時に復旧が長引く
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. 「小さく頻繁にリリースする」ほうが安全とされる主な理由は？
問2. CI/CDのパイプラインを起動する「トリガ」の例として正しいのは？
問3. パイプラインを構成するビルドやテストなどの各段階の呼び方はどれ？
問4. いきなり本番へ出さず、本番同等の環境で最終確認してから配るための段階はどれ？
問5. 「ロールバック」の説明として正しいのは？
問6. 同じ成果物を各環境へ配る（作り直さない）ことの利点として正しいのは？
問7. ソース取得→ビルド→テスト→デプロイと自動でつながった一連の段取り全体を、カタカナで何と呼びますか。
問8. ビルドで出来上がり、各環境へ同じ物を配る「配布物（成果物）」をカタカナで何と呼びますか。