落ちる変更が2割ある前提で計算しました。E2Eを先に置くと、落ちるまでの待ちは455.4秒です。
速い段から並べ替えると148.0秒になりました。同じ変更、同じ検査です。
検査の中身は同じでも、並べる順番で待ちが変わります。落ちる変更ほど効きます。
CI/CDでは、いくつかの検査を順に走らせます。その順番で待ち時間が変わることを実際に計算しました。
段は4つです。書式検査10秒・単体テスト60秒・組み立て120秒・E2Eテスト400秒としました。
落ちる割合も段ごとに置きました。変更2万件のうち4247件（21.2%）がどこかで落ちます。
変更 20000件。段ごとに落ちる割合は 書式6%・単体10%・組み立て3%・E2E4% どこかで落ちる変更は 4247件（21.2%） 並べ方 1件あたりの時間 合計時間 落ちた変更の平均待ち 速い順に置く 496.1秒 9922920秒 148.0秒 組み立てを先に置く 512.4秒 10248330秒 224.6秒 E2Eを先に置く 561.4秒 11228380秒 455.4秒 全部まとめて並列 400.0秒 8000000秒 400.0秒
右端の列を見てください。E2Eを先に置くと、落ちる変更は455.4秒待たされます。
速い順に並べ替えると148.0秒です。3分の1以下になりました。
書式検査は10秒で、6%の変更がここで落ちます。落ちた時点で、後ろの580秒は走りません。
E2Eを先に置くと、書式の誤りでも400秒待ってから落ちます。直せば分かる誤りに、7分近くかけていることになります。
出典もこの向きを頻繁に反映するほど誤りは早く見つかり、原因を探すときに調べるコードの量も減ると述べています。早く知ることに価値があります。
手前で落とせば、後ろの段は走らない。
Committing code more often detects errors sooner and reduces the amount of code a developer needs to debug when finding the source of an error.原文GitHub Docs「Continuous integration」 この内容の有効期限2027-02-18
並列は待ちを縮めます。落ちる変更にも全段ぶんを走らせるので、使う量は増えます。
CI/CDの費用は、実行した時間の合計で決まります。並べ方はここにも効きます。
表の合計時間の列を見てください。速い順は9922920秒、E2E先頭は11228380秒です。
同じ検査をしているのに、13%の差が付いています。手前で落ちれば、後ろの段の時間を払わずに済むためです。
全部まとめて並列にすると、1件あたりは400.0秒で最短になります。最も遅い段の時間だけで済むからです。
合計時間も8000000秒と、表の中で最小です。ただしこれは、待ち時間の合計です。
実際に使う計算資源は、4段ぶんが同時に走ります。書式の誤りでも、E2Eを400秒ぶん走らせます。
実務では両方を使います。速い段だけ先に順番で走らせ、通ったら残りを並列にする形です。
この計測でいえば、書式検査10秒を関門にします。6%はここで止まり、残り94%だけが重い段へ進みます。
出典も目的をコードを反映したとき、その変更が誤りを持ち込んでいないことを確かめるため、継続的に組み立てと試験を行えるとしています。確かめる中身は変わりません。
When you commit code to your repository, you can continuously build and test the code to make sure that the commit doesn't introduce errors.原文GitHub Docs「Continuous integration」 この内容の有効期限2027-02-18
並べる基準は2つの数字です。1件あたりの時間と、その段で落ちる割合を測っておきます。
CI/CDの段を並べ替えるには、段ごとの2つの数字が要ります。時間と、落ちる割合です。
1番目と2番目から並び順が決まります。短くて落ちやすい段を先に置きます。
この計測では書式検査が10秒で6%でした。単体テストは60秒で10%です。どちらもE2Eの400秒より手前に置く価値があります。
落ちる変更が少なければ、並べ替えの効果も小さくなります。ほとんど通るなら、どの順でも全段を走ります。
この計測では21.2%が落ちました。この割合が下がるほど、4つの並べ方の差は縮みます。
手前で落とすと、原因の絞り込みも楽になります。出典もテストが落ちたとき、あなたの変更のどれかが失敗の原因かもしれないと書いています。
段が細かいほど、落ちた段そのものが原因の手がかりになります。ユニットテストの記事では、層ごとに届く欠陥が違うことを測っています。
並べ替えの効き目は、落ちる変更の割合で決まる。
段ごとの時間と落ちる割合は置いた値です。実際の並び順は依存関係でも縛られ、組み立てをしないとテストが動かないこともあります。並列の合計時間も、待ち時間の合計として数えたもので、使った計算資源とは別です。ここで見せているのは、手前で落とせば後ろの段を払わずに済むという関係です。
When a test fails, one of your changes may have caused the failure.原文GitHub Docs「Continuous integration」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る