build単価とは？ CIのユニットエコノミクスを測る

build単価とは、1つの完全なpipelineを実行するためにCIが費やす平均額であり、CIが効率的かどうかを教えてくれるユニットエコノミクスの指標です。

CI支出の総額は請求の規模を教えてくれます。build単価は、各実行が効率的かどうかを教えてくれます。それは無駄をあぶり出し、pipeline同士を比較でき、最適化が実際に効いたかを示す指標です。CIコストの数字を1つだけ追跡するなら、これは有力な候補です。

計算方法

build単価は、一定期間の総コンピュートコストを、その期間のpipeline実行回数で割ったものです。5,000回の実行で$1,000を使ったなら、build単価は$0.20です。job単位で計算し、pipeline全体で合算すれば、より詳細に把握できます。

何が押し上げるか

長いjob、大きなrunner、多くのmatrixのレッグ、flakyな再実行は、いずれもbuild単価を上げます。平均であるため、ごく少数の非常に重い実行（macOS、大きなmatrix）が、数字全体を引き上げることがあります。

総支出に勝る理由

総支出は、たとえ各buildが効率的でも、チームが成長するにつれて上がります。build単価はボリュームで正規化するため、buildの回数に関係なく、時間とともに効率が上がっているか下がっているかを示します。

最適化の狙いに使う

build単価でpipelineをランク付けし、最悪のものから攻めます。数千回実行される1つの高価なworkflowが、請求を支配しうります。そのcachingやrunnerサイズを直せば、数字全体が動きます。

時間を通じて追跡する

build単価をリリースをまたいでプロットします。じわじわ上がる数字は、新たな無駄 - 遅いテスト、過大なrunner、増すflakiness - を知らせ、より大きな請求書として現れる前にリグレッションを表面化させます。

build単価を下げる

cacheしてjobを短くし、runnerを適正サイズにし、flakyな再実行を潰し、それからレートを下げます。Latchkeyのmanaged runnerは、同じpipelineをGitHub-hostedよりおよそ70%安く実行することで、build単価を直接下げます。/learn/github-actions-cost-calculatorでモデル化しましょう。

重要なポイント

build単価 = 総コンピュートコスト ÷ pipeline実行回数。
ボリュームで正規化するため、総支出が隠す効率をあぶり出します。
これでpipelineをランク付けし、最も高価なworkflowから狙います。