CI/CDパイプライン — 関所を落ちたら、先には進まない

CI/CDは「コードを push したあと、人間が手でやっていた作業を全部まとめて機械に任せる」仕組みです。ビルドして、テストして、問題なければ本番へ出す。この一連の流れをパイプラインと呼び、工程ごとにステージという関所を置きます。

ポイントは関所を1つでも通れなければ、その先には絶対に進まないこと。壊れたコードが本番へ流れ出るのを、機械が問答無用で止めてくれます。下の図1で実際に push して、流れる様子と止まる様子を確かめてください。

ステージ — 関所を順番に、確実に

パイプラインはステージという順序つきの関所でできています。典型的なのは Build（動く形にまとめる）→ Test（壊れていないか調べる）→ Deploy（本番に出す）の3つ。

この順番には意味があります。安くて速い検査を前に、高くて遅い検査を後ろに置くのが定石です。コンパイルすら通らないコードに30分のE2Eテストを回すのは無駄なので、まずビルドで弾く。図1でも、BUILDが落ちればTESTは1つも走りません。

並列実行 — 待ち時間は「一番遅い1つ」まで縮む

同じステージの中のジョブは、互いに依存していなければ同時に走らせられます。LintとユニットテストとE2Eテストは、お互いの結果を必要としません。だから3つ同時に流せば、そのステージにかかる時間は合計ではなく「一番遅い1つ」になります。

図1の上のタブで直列に切り替えて push してみてください。同じ内容なのに待ち時間が大きく伸びます。CIの改善で最初に効くのは、たいていこの並列化と、遅いジョブそのものを速くすることです。パイプライン全体の時間は、結局一番長い経路の長さで決まります。

失敗したら、その先へは進まない

ジョブが1つでも失敗すると、そのステージは失敗になり、後続のステージは実行されません。図1でE2Eテストを壊してから push すると、DEPLOYが灰色のままスキップされるのが分かります。

一方、同じステージの中で並走している他のジョブは、そのまま最後まで走ります。「Lintも落ちているのか」「ユニットテストは通るのか」を1回の実行でまとめて知りたいからです。もし直列にしていたら、最初の失敗で止まってしまい、残りの問題は次の push まで見つかりません。これも並列にする理由のひとつです。

まとめ

CI/CDパイプラインの本質は「順番に並んだ関所」と「落ちたら先へ進まないという約束」だけです。ステージを分けることで安い検査から先に回せ、ジョブを並列にすることで待ち時間を一番遅い1つまで縮められる。そして失敗したときに何もしないことが、この仕組みが本番を守っている瞬間です。