flakyなpipelineのコストとは？隠れたCI税

flakyなpipelineとは、実際のコードの問題がないのに断続的に失敗するpipelineであり、そのコストは3つの形で現れます。無駄なminute、失われたエンジニアリング時間、そして遅くなった配信です。

flakyなpipelineはあまりに一般的なため、チームはそのコストに気づかなくなります - ただjobを再実行して先に進むだけです。しかし各再実行は同じ作業を二重に課金し、エンジニアを中断させ、リリースを後ろへ押しやります。その税を定量化すると、しばしば目を見張らされます。そしてそれを取り除くことは、得られるCI投資の中でも最も高いリターンの1つです。

再実行による無駄なコンピュート

再実行されるflakyな失敗は、そのたびにjob全体を再び課金します。実行の10%が一度再実行されるなら、追加価値ゼロでおよそ10%余分なコンピュートを支払っていることになります。月$1,000のCI請求では、それは毎月$100の純粋な無駄です。

失われるエンジニアリング時間

通常、人間が失敗に気づき、それがflakyだと判断し、再実行をクリックし、そして待たなければなりません。そのコンテキストスイッチは、minuteよりはるかに大きなコストです。チーム全体では、flakyなトリアージの時間はコンピュートの無駄を凌駕しうります。

遅延した配信

リリースブランチでのflakyな失敗は、誰かが介入するまでmergeをブロックしうります。品質をゲートするはずのpipelineが、代わりにスループットをゲートし、リードタイムを長くし、deploy頻度を下げます。

信頼の侵食

失敗が日常的に「ただのflaky」とされると、エンジニアは赤いbuildを無視し始めます - 本物の失敗も含めて。flakyなpipelineのコストは、やがて、誰もシグナルを信頼しないためにすり抜けるバグをも含むようになります。

定量化の方法

再実行率を追跡し、コンピュートコストを掛けて直接の無駄を求め、次にflakyな失敗1件あたりのトリアージ時間にその頻度を掛けて見積もります。/learn/github-actions-cost-calculatorにある計算ツールは、flakyな再実行を直接モデル化するため、ドルの数字を確認できます。

flaky税を取り除く

本当にflakyなテストを安定させ、それ自体がflakinessを加えないインフラを使います。Latchkeyのmanaged runnerは、一時的およびインフラ由来の失敗を自動的に自己修復し、人がbuildに触れることなくflakyな再実行のminuteの大半を回復します。しかも分あたりのコストがおよそ70%安いのです。

重要なポイント

flakyなpipelineは、再実行を通じて同じ作業を二重に課金します。
失われるエンジニアリングのトリアージ時間は、通常コンピュートの無駄を上回ります。
flakyなbuildは配信を遅らせ、CIのシグナルへの信頼を蝕みます。