CI/CD

**継続的インテグレーション(CI)**は、プッシュやプルリクエストごとにコードを自動的にビルド・テストする。**継続的デリバリー/デプロイメント(CD)**はこれを拡張し、成果物(Dockerイメージ、バイナリ)のパッケージングとリリースを自動化する。SLAMプロジェクト——重量級の依存関係と複数のターゲットプラットフォームを持つ大規模なC++コードベース——において、CIはビルドを健全に保つための仕組みである。

GitHub Actions

GitHub Actionsは、オープンソースのSLAM開発においてデファクトスタンダードなCIサービスである。ワークフローは.github/workflows/内のYAMLファイルであり、トリガー(push、pull_request、スケジュール)によって、新規のランナーVMまたはコンテナ内で実行される。

name: build
on: [push, pull_request]
jobs:
  build-and-test:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: sudo apt-get update && sudo apt-get install -y libeigen3-dev libopencv-dev
      - name: Configure and build
        run: cmake -B build -DCMAKE_BUILD_TYPE=Release && cmake --build build -j
      - name: Run tests
        run: ctest --test-dir build --output-on-failure

SLAMリポジトリに有用なパターン。

• ビルドマトリクス: Ubuntuのバージョン、コンパイラ、ROSディストリビューションを並行してコンパイルする。

  strategy:
    matrix:
      os: [ubuntu-22.04, ubuntu-24.04]
      build_type: [Release, Debug]

• Dockerベースのジョブ(container: my-org/slam-dev:latest): 開発者が使うのと同じイメージ内でワークフローを実行し、「CIでは動く」が「どこでも動く」ことを意味するようにする。

• キャッシュ(actions/cache): サードパーティ依存関係(Eigen、Ceres、OpenCV)のコンパイル結果をバージョンでキー付けしてキャッシュする——C++プロジェクトにおいて5分と45分のCI実行時間の差を生む。

• 成果物とリリース: 各実行からビルド済みバイナリ、wheel、評価レポートをアップロードする。タグトリガーのワークフローは、Dockerイメージを自動的に公開できる(CDの半分)。

• セルフホストランナー: GPUに依存するジョブ(CUDAカーネル、学習済みフロントエンド)やARMクロスビルドは、標準ランナーにGPUがないため通常セルフホストランナーが必要になる。

SLAMプロジェクトで自動化すべきこと

1. コミットごとのビルド——テンプレートを多用するC++コードは、これがないと静かに壊れる。
2. 数学ユーティリティ(幾何、ヤコビアン)の単体テスト——安価で、最悪のバグを捉えられる。
3. 小規模な回帰テスト実行: 短いデータセットのシーケンスを処理し、ATE/RPEを閾値と比較する。これにより、精度の劣化がマージ前に発見される。ジョブの再現性を保つため、シーケンスはリポジトリに格納する(または固定バージョンを取得する)。
4. リンティング/フォーマッティング(clang-format、clang-tidy): 複数の貢献者がいるコードベースの一貫性を保つ——CIで強制することでスタイル論争を終わらせる。

よくある落とし穴

• 不安定な精度ゲート: SLAMは確率的(RANSAC、スレッド)であるため、観測された平均値に厳格なATE閾値を設定するとランダムに失敗する。可能な限りシードを固定し、マージンを持って閾値を設定するか、複数実行の平均を取ること。
• CI環境のドリフト: バージョンを固定しないapt-get installは、あなたの知らないうちにビルドを変化させる。バージョンを固定するか、バージョン管理されたDockerイメージ内でビルドすること。
• Releaseビルドのみのテスト: (アサーションとサニタイザーを含む)Debugビルドは、Releaseビルドでは隠れてしまうメモリバグを捉える——少なくとも夜間には両方を実行すること。
• 実行時予算の無視: 精度に影響しないがフレームあたりのレイテンシを倍にする変更も回帰である。回帰ジョブでタイミングを記録し、閾値を設けること。

SLAMにおける意義

SLAMシステムは、センサードライバ、サードパーティのソルバー、プラットフォーム固有のSIMDなど、多くの脆弱な部品を結合している。あなたのラップトップでビルドできる変更が、ロボットのUbuntuイメージでは日常的に壊れる。CIはこれを数分以内に捉え、データセットベースの回帰ジョブは、「私のリファクタリングは精度を悪化させたか?」という問いを、手作業の午後の雑用から自動チェックに変える。産業界のSLAMチームは、CIパイプライン(ビルド、テスト、ベンチマーク、パッケージング)をプロダクトの一部として扱う。

関連ノート

• Git/GitHub
• Docker
• Bash/Linux
• Metrics