Continuous Integration (CI)

継続的インテグレーション (CI)とは、各開発者の変更を少なくとも毎日、頻繁に共有のmainブランチへマージし、変更ごとにビルドとテストを自動実行する取り組みです。これにより、統合時の問題をリリース時ではなく数分以内に発見できます。Grady Boochは1991年にこの用語を提唱し、Kent Beckは1990年代後半にエクストリームプログラミングの中核的なプラクティスとして取り入れました。Martin Fowlerの継続的インテグレーションの記事では、現在も多くのチームが採用するワークフローが説明されています。機械学習 (ML)では、変更によってモデルの精度が低下しても、すべてのユニットテストに合格する可能性があるため、CIではデータ、トレーニングコード、モデルの動作も確認します。

CIパイプラインの仕組み#

開発者がブランチをプッシュするかプルリクエストを作成すると、GitHub Actions、GitLab CI/CD、JenkinsなどのCIサービスが新しいランナーを起動し、コードをチェックアウトして依存関係をインストールし、リンターと型チェッカー、ユニットテスト、統合テスト、パッケージやコンテナイメージのビルドなどのジョブを実行します。各ジョブのステータスはプルリクエストに報告され、ブランチ保護ルールを設定すれば、必須チェックがすべて合格するまでマージを禁止できます。パイプラインでは、複数のOSやPythonバージョンの組み合わせで同じテストを繰り返すことがよくあります。また、mainブランチではマージのたびに全テストスイートを再実行します。速度もこのプラクティスの重要な要素です。Beckのエクストリームプログラミングでは、システム全体のビルドと全テストの実行を10分以内に完了する目標を定めました。ビルドに時間がかかると、実行頻度が下がるためです。

機械学習におけるCI#

MLプロジェクトには独自のチェックが加わります。データテストでは、新しいトレーニングデータが想定スキーマに一致すること、すべてのラベルファイルを解析できること、同じ画像がトレーニング用と検証用の両方に含まれてデータリークを起こさないことを確認します。小規模なデータセットで1 エポックだけ学習するスモークテストにより、形状エラーやクラッシュを数分以内に検出できます。モデル出力を比較するテストでは、乱数シードを固定し、小さな数値誤差を許容します。GPUカーネルやデータ読み込み順序によって、実行ごとに浮動小数点の結果が変わる可能性があるためです。品質ゲートは固定された検証セットでモデルを評価し、平均適合率 (mAP)などの指標が設定した下限を下回るとビルドを失敗させます。また、エクスポートテストでは、ONNX版やTensorRT版のモデルが元のモデルと同様に読み込み、スコアを出せることを確認します。完全なトレーニングには時間がかかり、GPUランナーも高価なため、通常、チームはすべてのプルリクエストで高速なチェックを実行し、完全な再トレーニングとモデルデプロイはスケジュール実行またはmainブランチで行います。DVCなどのバージョン管理ツールを使えば、各ジョブが必要とする正確なバージョンのデータセットを取得できます。

Ultralytics YOLOのベンチマークモードは、このようなゲートとして機能します。verboseに0.216などのfloat値を設定すると、エクスポートに失敗した場合や、エクスポートしたいずれかの形式のmAP_50-95が下限を上回らなかった場合にエラーを発生させます。Ultralyticsリポジトリ独自のCIでは、この機能を使ってLinux、macOS、ARMの各ランナーでYOLO26のエクスポートをテストします。ユニットテストとこのゲートを組み合わせた最小限のGitHub Actionsワークフローは次のとおりです。

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

すべてのプルリクエストとmainへのすべてのプッシュで、新しいUbuntuランナー上でジョブが実行されます。ユニットテストの失敗、または小規模なCOCO8データセットで下限以下のスコアを出したONNXモデルがあると、変更をマージする前にチェックが失敗します。

CIとCD、MLOps、継続的トレーニングの比較#

• 継続的デリバリー (CD)：CIに合格したビルドをリリースできる状態に保ち、多くの場合はステージング環境へ自動デプロイします。継続的デプロイメントはさらに一歩進み、合格した変更をすべて本番環境にリリースします。
• MLOps：MLライフサイクル全体にわたって、CIとCDにデータのバージョン管理、モデルデプロイ、モニタリング、再トレーニングを組み合わせる、より広範な分野です。
• 継続的トレーニング (CT)：新しいデータが届いたときや、モニタリングでドリフトが検知されたときに、モデルを自動で再トレーニングして再デプロイします。GoogleのMLOps成熟度レベルでは、自動再トレーニングはレベル1、トレーニングパイプライン自体の自動CI/CDはレベル2に位置付けられています。