Linear で CI パフォーマンスを大幅に向上させた 14 つの対策

Linear の CTO トーマスは今年初め、「CI コストが高い」という課題と、CI の高速化という二つのタスクを私に割り当てました。コードのデプロイはエージェントによって劇的に加速されましたが、PR の検証速度はそれに追いついておらず、CI は開発活動のボトルネックとなっていました。

成果の概要

テストスイートがほぼ 4 倍 に増えたにもかかわらず、以下の指標を大きく改善しました。

• PR 待機時間: 6 分以上 → 5 分未満（削減）
• テストあたりのランナー時間: 約半分に削減

改善の 4 つの観点

Linear のコードベースは TypeScript ですが、これらの手法は言語やツールチェーンを超えて広く応用可能です。

1. インフラストラクチャとツールのアップグレード
2. 他の作業を制御するジョブの最適化
3. 繰り返しのセットアップの削減
4. テスト実行効率の向上

---

1. インフラストラクチャとツールのアップグレード

CI パイプライン自体を変えず、基盤を強化することで大きな改善を行いました。

• ランナーの移行: GitHub Actions から、高性能 CPU・高速ストレージ・優れたキャッシュインフラを備えたサードパーティ製ランナーへ移行。
  • ジョブ実行速度平均：34% 向上

  • tsc

    （TypeScript コンパイル）のような特定負荷：52% 削減
• コンパイラーの近代化:

  tsc

  からネイティブコンパイラ

  tsgo

  に切り替え。

  • tsc チェック

    の中央値：73% 削減
  • ボトルネック（型チェック）が完全に解消されました。

2. タイプチェッカーを使わないリンティング

型情報を必要とするルールを再実装し、メモリ消費量の多いリンティングジョブを軽量化しました。

• 手法の転換: 型情報への依存を断ち、AST（抽象構文木）のみを静的解析する方式へ変更。
  • API リンティング時間：68% 削減
  • リポジトリ全体のリンティング時間：55% 削減
  • メモリ使用量：大幅に減少。
• Oxlint への移行: 型依存を断つことで、

  Oxlint

  へのシームレスな移行が可能になり、CI ランナー時間をさらに削減しました。

3. 他の作業を制御するジョブの最適化

インフラ速度が向上したことで、クリティカルパス上の「小さなジョブ」への注目が集まりました。

• 変更検出ジョブ: PR がどのファイル（パス）を変えたかを確認する前のゲート処理を高速化。
• 取得データの最適化:
  • 完全な動作ツリーをチェックアウトせず、必要な小規模なサブセットのみを取得。
  • チェックアウト深さを制限し、不要なジョブからはチェックアウトを完全に排除。
• ネットワーク安定性への対応:
  • サードパーティランナーは GitHub 外にあり、IP 接続が不安定な場合があります。

  • actions/checkout

    を自前製コンパウンドアクションへ置き換え、後退戦略（backoff）付きリトライを実装。

  • GIT_HTTP_LOW_SPEED_LIMIT

    /

    TIME

    を設定し、停滞時に約 30 秒後に強制終了させることで固まりを防止。
  • ステイクリーディスク上に永続的な git ミラー（チェックアウトキャッシュ）を維持。

4. 繰り返しのセットアップを削減

各ジョブで繰り返されるオーバーヘッド（起動、インストール、ビルドなど）を劇的に削減しました。

• 共有依存関係の事前インストール: CI イメージ内に Postgres クライアントなどを

  apt

  でインストールし、再インストール時間を排除。
• 必要な依存関係のみをインストール:

  • pnpm

    ワークスペース全体をインストールせず、必要なパッケージ（API パッケージ）のみを対象化。
  • 後続ジョブでほぼ使われないキャッシュアップロード処理も排除。
  • 結果：

    pnpm install

    は 44〜73 秒 → 16〜18 秒に。
• キャッシュの再考:

  node_modules

  キャッシュは復元に時間がかかり、ばらつきを増やすのみであるため不要と判断し、キャッシュ使用を停止。

さらに、入力が変わらないセットアップを再実行しない工夫も施しました。

• スキーママイグレーションの最適化: フル履歴の再プレイではなく、スナップショットファイルを読み込むことで、セットアップ時間を 12 秒 → 1〜2 秒に削減。
• 短いチェックのバッチ化: 7 つの独立した小規模ジョブ（それぞれ起動・インストールなど）を統合し、2 つのジョブ内で並列実行。
  • セットアップコスト支払い回数：7 回 → 2 回へ削減。
  • 月間ランナー分節約：87,000 ランナー分（CI 使用量の 11.8% に相当）。

5. テスト実行をより効率的にする

固定コストを下げることで、API スイートの並列化をさらに促進しました。

• ワークロードのバランス:

  Vitest

  はファイル単位で分散するため、巨大なテストファイルがシャードを支配していました。
  • 大規模ファイルを分割・焦点化し、シャード数を適切に増加（初期は 3→4、現在は 8 シャード）。
  • 結果：最も遅いシャード時間は 5.25 分 → 4.33 分へ。
• 共有状態の活用:

  isolate: false

  オプションを有効化し、再構築コスト（エンティティ・グラフなど）を削減。
  • 最も遅いシャード時間：約 379 秒 → 195 秒へ。
  • API シャードランナー全体時間：約 32.8 分 → 22 分へ。
  • 月額コスト：約 17% 削減。
  • 注意: 共有状態によるリスクを回避するため、対象ファイルごとに明示的な

    opt-in

    コメントと適切なクリーンアップ実装が必要です。

6. シャーディングの限界について

シャーディングは有効ですが、セットアップオーバーヘッドが低く限定的です。

• シャード数を 2 倍にしても、セットアップ時間は 2 倍になるため、メリットが減ってしまいます。
• セットアップ時間が約 40 秒まで低下したことで、8 シャードにおける総セットアップ時間が 4 シャード時より少なくなるようになり、並列化度を 2 倍に高めることができました。

システム全体での波及効果

今年初めの意図的な改善努力がなければ、現在のテストスイートは約 11 分かかったでしょう（開発者が待つ時間のほぼ 2 倍）。

• この改善は完了ではなく、コードベースの成長（週に約 2,000 のテスト追加）に合わせて継続的な取り組みが必要です。
• これまでの知見を応用し、新たなボトルネックへの対応を通じて CI を高速化し続けることが重要であるためです。