組み込みCI/CD入門
組み込み開発においては、ハードウェア依存や再現性といった問題により、CI/CDの導入が困難でした。しかし、CIツールやシミュレータ技術の進化により、組み込み開発においてもCI/CDの導入による継続的な品質管理が可能となってきました。
そこで本記事では、組み込みCI/CDの基本からハードなしテスト、HIL実装、静的解析、成果物管理に至るまでのCI/CD導入について解説します。
組み込みCI/CDと導入における課題
組み込み開発にCI/CDを導入する際には、Webシステム開発とは異なる制約条件があることを理解する必要があります。ここではまず、CI/CDの基本的な知識と、組み込み開発特有の課題について整理します。
CI/CDの概要と役割
CI（継続的インテグレーション）は、ソースコード変更時にビルドやテストを自動実行し、不具合を早期に検出する仕組みです。一方のCD（継続的デリバリー／デプロイメント）は、CIに続けて、リリースやデプロイまでを自動化する考え方を指します。
近年では、GitHub Actionsなどを利用し、pushやPull Request（PR）をきっかけとして自動的にビルドやテストを実行する構成が一般的です。組み込み開発においてもソフトウェアの規模拡大に伴い、品質の維持と開発の効率化を両立する手段としてCI/CDの重要性が高まっています。
組み込み特有の課題
組み込み開発でのCI/CD導入においては、ハードウェア依存が大きな障壁です。実機なしにはテストができないコードが多いものの、実機台数には限りがあるため、自動テスト環境を構築しにくいことが原因です。
また、クロスコンパイル環境やツールチェーンの差異によって、開発者ごとにビルド結果が変わりやすいという問題もあります。さらに、実機は、ベアメタルのようにOSが乗っていないような場合もありますし、搭載されていたとしても、低レベルなOSである場合が多いです。そのため、実機テストは準備や実行にかかる時間が長く、CI/CDパイプライン全体のボトルネックになりやすい点も課題です。
本記事のスコープ
組み込みCI/CDでは、単に自動テストを導入するだけでは十分ではありません。重要な点は、「ハードなしテスト→HIL→成果物管理」といった段階的な構成を設計し、継続的な品質管理を実現することです。
本記事では、CI/CDを単なるテストの自動化ではなく、「開発基盤」として整備する考え方を中心に解説します。
ハードなしテストでのCI統合
組み込みCI/CDでは、まず実機を用いずにテスト可能な範囲について整理することが重要です。実機なしでどこまでテストできるのか、ハードなしテストの概要とCIへの統合方法を確認していきます。
シミュレータの活用
シミュレータを利用すると、実機がなくてもCI環境でテストを実行可能です。これにより、開発初期から継続的にビルドやテストを回せるようになり、不具合の早期検出が可能になります。
また、サーバー上で同一のCI環境を再現しやすいため、「開発者の手元では動作するがCI環境では失敗する」といった問題も減らしやすいメリットがあります。
モック・スタブの設計
ハードウェアに依存するコードをそのままテストすることは難しいため、モックやスタブを用いてハードに依存する部分の抽象化が重要です。
たとえば、GPIOやUARTといったI/O部分をインターフェース化し、テスト時には擬似的な実装へ差し替えることにより、ロジック部分だけを自動でテスト可能になります。これにより、ハードウェア依存を減らしつつテスト範囲を拡大できます。
CIへの統合
GitHub Actionsなどを利用すると、push/PRをきっかけとしてビルドやテストを自動的に実行できます。テストに失敗した際にはマージを禁止することによって、不具合の混入を防ぐことが可能です。
また、CIワークフローをYAMLで管理することにより、ビルド手順やテスト内容をコードとして共有できるため、属人的な運用を減らせるでしょう。
HILにおける統合テストの実装
シミュレータだけでは確認できない問題に対しては、HIL（Hardware-in-the-Loop）による実機テストが重要です。本章では、HILの概要と、テストへの導入方法を取り上げます。
HILの概要
HILでは、実際のハードウェアを接続した状態でテストを実行します。タイミング依存の問題やセンサ入力に関する不具合など、ソフトウェアによるシミュレータだけでは再現しにくい問題を検出できる点が特徴です。
そのため、HILは多くの場合に品質保証における最終段階として位置付けられます。
CI/CDとの連携
HILの実行は長時間にわたりやすいため、多くの場合CIパイプラインの後段に配置されます。たとえば夜間バッチとして実行し、結果を自動収集・可視化する構成が一般的です。
また、テストログを継続的に蓄積することにより、不具合解析なども効率化しやすくなります。
導入における課題
HIL導入時には、実機の使用配分やテスト時間の増加といった課題が発生しやすいでしょう。特に複数チームで同一設備を利用する場合には、設備の予約や排他制御が必要です。
そのため、「ハードなしテスト」と「HIL」の役割を明確に分けたテスト戦略の設計が重要となります。
品質ゲートとしての静的解析
CI/CDでは、テストだけではなく静的解析による品質確認も重要です。静的解析の概要を整理した上で、CI/CDとの統合方法と運用時の注意点を見ていきましょう。
静的解析とは
静的解析は、コードを実行せずに潜在的な問題を検出する技術です。初期化していない変数やNULLの参照、MISRA Cに対する違反などの早期検出が可能な点が特徴です。
レビュー前の段階で問題を把握できるため、レビューの負荷軽減にもつながります。
CI/CDと静的解析の統合
静的解析は、一般的にはPR作成時に自動実行する構成となります。解析結果をCIの合否判定に利用することによって、品質基準を継続的に維持しやすい点が特徴です。
また、テストと同時に実施することにより、品質確認を一元化できる点もメリットです。
運用時のポイント
静的解析では、警告数が増えすぎると形骸化しやすくなります。そのため、警告の重要度に応じた品質ゲートをあらかじめ設定し、段階的に改善していく運用が重要です。
「警告ゼロ」を目指すのではなく、継続的に品質を改善していくことが現実的です。
成果物管理とリリース運用
CI/CDでは、ソースコードだけでなく、その他の成果物やログを含めた管理も重要です。成果物管理の重要性とその方法に加え、トレーサビリティの確保についても取り上げます。
成果物管理の重要性
組み込み開発では、バイナリやマップファイル、ログなどの適切な管理が重要です。特に不具合の解析時には、「どのソースコードから生成された成果物か」を追跡できる必要があります。
そのため、GitだけではなくCI/CD上でも成果物を一元的に管理する仕組みが求められます。
CI/CDによる管理方法
GitHub Actionsでは、ビルド成果物をアーティファクトとして自動保存することが可能です。これによって、成果物をバージョン単位で管理しやすくなります。
また、リリースタグと成果物とを紐付けることによって、再現性のあるリリース運用の実現が可能となります。
トレーサビリティの確保
成果物とソースコード、テスト結果、静的解析結果を関連付けることによって、不具合発生時における原因の追跡を効率化できます。
品質証跡を残すことは、長期的な保守や認証対応の観点からも重要です。
