CIを速くする施策は、開発者が結果を待つ時間と、実行環境が消費する時間へ異なる影響を与える。 多数のジョブへ分割すれば待ち時間を短縮できるが、環境の起動、リポジトリの取得、依存関係の導入を分割数だけ繰り返すため、ランナー時間は増えうる。 反対に短い検査を一つのジョブへまとめればランナー時間を減らせるが、並列性を失う構成では待ち時間が延びる。
したがって、CIの所要時間を一つの値として改善すると、費用を増やして速くしたのか、待ちを増やして安くしたのかを区別できない。 開発者やコーディングエージェントが結果を得るまでの待ち時間と、全ジョブが消費した計算時間の合計であるランナー時間を別々に測る必要がある。 これは業務の所要時間を実作業と待ちに分解する考え方をCIへ適用したものでもある。
Linearは、テストスイートが年初から約4倍になった期間に、プルリクエストの待ち時間を6分超から5分強へ短縮し、テスト一件当たりのランナー時間を約半分にした。 この改善は、単にテストを並列化した結果ではない。 先に各分割の固定費を下げたことで、待ち時間とランナー時間を同時に減らせる範囲が広がった。
たとえば、各テスト分割はモノレポ全体ではなく必要なパッケージだけを導入し、データベースの移行履歴ではなく生成済みのスキーマを読み込むようにした。 依存関係は、復元に約28秒かかるキャッシュを使わず、約7.5秒で再導入した。 短い七つの検査は二つのジョブへまとめ、準備処理の重複を減らした。 この統合だけで、月間ランナー時間を全体の11.8%に当たる約8万7,000分削減した。
固定費を下げた後には、テストを四分割から八分割へ増やせた。 改善前は各分割の準備に110秒から140秒かかっていたため、八分割すると準備だけで合計15分から19分を消費していた。 準備を約40秒まで短縮すると、八分割の合計準備時間は改善前の四分割より短くなり、テスト本体も二倍の幅で並列化できる。
待ち時間はクリティカルパス上の短い処理にも左右される。 Linearは、変更検出ジョブの不要なチェックアウトを除き、その中央値を26秒から8秒へ短縮した。 マージに不要なキャッシュ書き込みも必須経路から外し、APIのプルリクエストを一律42秒短縮した。 個々の処理時間だけでなく、後続のいくつのジョブを待たせるかによって改善の優先順位を決めている。
CIを最適化するときは、まず待ち時間とランナー時間を測り、クリティカルパスとジョブごとの固定費を特定する。 その後で、固定費の削減、短い処理の統合、負荷の偏りの解消、分割数の増加を組み合わせる。 コード生成が速くなるほど検証へ流れ込む変更も増えるため、この測定は人間のレビューへ届く前の検証基盤を拡張する条件になる。