【要約】複数 Poetry プロジェクトを持つ Python マイクロサービスの CI 戦略 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が1つのリポジトリで複数のPoetryプロジェクトを管理するモノレポ構成において、CIの実行時間が肥大化するという課題がある。プロジェクト数が増えるにつれ、以下の問題が顕在化する。
- ・Pull Requestのたびに全プロジェクトのテストが走り、開発者の待ち時間が長くなる。
- ・CIリソースの浪費が発生し、実行コストが増大する。
- ・プロジェクト間の依存関係や設定変更が、意図せず広範囲のテストを誘発する。
// Approach
開発チームは、GitHub Actionsの
matrix 機能と git diff を組み合わせ、検証対象を動的に制御する手法を採用した。具体的なステップは以下の通りである。- ・
discoverジョブで全プロジェクトを検出し、JSON形式の配列として出力する。 - ・Pull Request時は
git diffを用い、変更があったプロジェクトのみを検証対象とする。 - ・CI設定ファイルやルートの
pyproject.tomlが変更された際は、安全のため全件検証に切り替える。 - ・
developへのマージ後は、全プロジェクトに対して一括でテストを実行する。 - ・Makefileを用いて、ローカル環境でも全プロジェクトの統合coverageを算出する仕組みを構築する。
// Result
この戦略を導入することで、開発者は変更箇所に特化した迅速なフィードバックを得られ、開発速度が向上する。
- ・Pull Request時のCI実行時間が、変更範囲に応じて最適化される。
- ・READMEへのテストステータスとcoverageバッジが自動更新され、品質が常に可視化される。
- ・モノレポ全体におけるテスト網羅率を、統合レポートとして一元的に把握可能になる。
Senior Engineer Insight
> モノレポ運用におけるCIのボトルネックを的確に解消する、極めて実践的な設計である。差分検知による
matrix の動的生成は、開発体験（DX）を維持する上で不可欠な技術だ。ただし、CIスクリプトの複雑性が増すため、CI自体の保守体制が重要になる。記事内で言及されている「develop push後のテスト重複」は、実装の明快さを優先した結果であり、実運用ではArtifactを利用した最適化が望ましい。大規模なマイクロサービス群を管理する現場において、即戦力となる構成である。