django-ci-test-optimization

Django CI テストの最適化

CI の最適化では、信頼性を損なうことなくフィードバック時間を短縮する必要があります。高速なローカルコマンドと CI の完全なカバレッジを区別し、キャッシュ、並列処理、適切な分割ポイントを活用して CI の実行を高速化します。

CI ワークフロー

1. 現在の CI の所要時間を記録します。

   • 依存関係のインストール、テストデータベースのセットアップ、テストの実行、成果物のアップロードを分けます。
   • CI の所要時間とローカルでの実時間を比較し、環境固有のオーバーヘッドを特定します。

2. まず依存関係をキャッシュします。

   • pip またはパッケージマネージャーのキャッシュには、CI に標準で備わっているキャッシュ機能を使用します。
   • プロジェクトがすでにそのパターンに対応している場合を除き、安全に変更できない可能性のある仮想環境ではなく、パッケージのダウンロードキャッシュをキャッシュします。

3. ローカルでのショートカットは、実態に即したものにします。

   • ローカルでの実行では、遅いテストを省略したり、データベースを再利用したりする場合があります。
   • CI では、遅いテストを実行し、少なくとも 1 つの実際のマイグレーションを使ったデータベースセットアップパスを設けます。

4. テストを計画的に分割します。

   • 遅いテストを示すマーカーが有用な場合は、遅いテストと通常のテストを分けます。
   • django-test-parallelization でテストスイートを安全に実行できるようになってから、並列ワーカーを使用します。
   • シャードを増やしすぎて、高コストなセットアップが重複しないようにします。

5. 明らかな無駄を取り除いてから、ハードウェアを強化します。

   • 高速なランナーが現実的な解決策となる場合もありますが、早すぎる段階で使うと、非効率なセットアップを覆い隠してしまいます。

コマンドと設定のパターンについては、ci-patterns.md を参照してください。

判断基準

• CI 専用の速度向上のためにテストコードを書き換える前に、依存関係のダウンロードをキャッシュします。
• pytest のマークを厳密に登録し、slow の誤記によってカバレッジが気付かないうちに変化しないようにします。
• ローカルコマンドで遅いテストを除外する場合は、それらを含めて実行する CI ジョブを追加します。
• ローカルでマイグレーションなしのショートカットを使う場合は、実際のマイグレーションを実行する CI パスを追加します。
• テストカテゴリが意図的に異なる場合はタグで分割し、テストスイートが十分に均質な場合はワーカーで分割します。
• タイミングデータを使ってシャードの境界を決めます。

よくある間違い

• 間違ったパスをキャッシュして、改善が見られない。
• ローカルでのスキップを既定にした後、遅いテストが CI から消えてしまう。
• シャードを増やしすぎて、データベースやセットアップのコストを何度も負担する。
• PostgreSQL／MySQL を本番で使うアプリの CI で SQLite を使用する。
• 共有リソースの問題を修正する前に、CI ワーカーの並列実行を有効にする。
• より大きなランナーを、プロファイリングの代わりとして扱う。

検証

完了する前に、次の点を確認します。

• CI で必要なすべてのテストカテゴリが引き続き実行される。
• 依存関係が変わるとキャッシュキーも変わる。
• テスト分割用のコマンドが文書化され、可能な範囲でローカルでも再現できる。
• 遅いテストまたはワーカーの分割によって、実際の CI ログで実時間が短縮されている。
• 逐次実行で再現するためのデバッグ用フォールバックコマンドがある。