DevOpsを組み込みシステムで使い始める方法：ATmega328Pを使用して

DevOpsとアジャイル手法は、コラボレーション、自動化、および継続的な改善を重視することでソフトウェア開発を変革しました。DevOpsの原則を私の設計とプロジェクトに適用することは、効率と信頼性を高めるゲームチェンジャーとなりました。この記事では、既存の組み込みシステムプロジェクトの継続的インテグレーション（CI）ワークフローを設定する方法を説明します。このプロジェクトはATmega328Pマイクロコントローラを使用しています。この記事の終わりまでに、これらの実践が開発プロセスを合理化し、より高品質な製品を提供する方法を見ることができます。

組み込みシステムのためのDevOpsとアジャイルを理解する

DevOpsは、ソフトウェア開発（Dev）とIT運用（Ops）を連続的な流れに統合する、ソフトウェア界で人気のある一連の実践です。ソフトウェア界では、ソフトウェアを開発し、「壁を越えて」運用担当者に顧客への展開を任せるのが一般的でした。DevOpsは、その壁を取り除くだけでなく、プロセス全体を自動化する方法を導入しました。ハードウェアの世界では、製品開発と生産の間に類似点があり、設計を製造エンジニアリングチームに「壁を越えて」投げ、生産の準備が整うように常に確認します。

組み込み製品設計では、ソフトウェアを生産を通じて進める必要がありますが、これまで以上に迅速に動き、可能な限り最高の品質で提供するという課題に直面しています。DevOpsの原則を用いることで、これらの課題のいくつかを解決することを目指しています。

• ハードウェアの依存性: 組み込みシステムはハードウェアとそれらのPCBの特定のリビジョンに依存しています。これは、自動化され高度にスケーラブルになるように合理化されていない場合、テストと展開を複雑にする可能性があります。DevOpsの実践は、ハードウェアとソフトウェアの両方に同じセットアップを使用し、自動化された継続的インテグレーション（CI）システムを通じてこれらのプロセスを自動化することで助けます。
• 長いビルド時間: 組み込みソフトウェアのビルドは設定が難しく、ビルド時間が長くなることがあります。CIは、ビルドをクラウドにオフロードすることでこのプロセスを自動化し、加速します。これにより、通常開発者がアクセスできないより強力なインスタンスを利用できます。
• 手動テスト: 実際のハードウェアでのテストは不可欠ですが、しばしば手動で、退屈で、時間がかかります。ハードウェア・イン・ザ・ループ（HIL）テストを通じた自動化は、効率と精度を向上させ、CIシステムで設定された自動テスト機器のセットアップにオフロードすることができます。

DevOpsの原則を適用することで、ビルド-テスト-デプロイのパラダイム内でアジャイル手法を使用して迅速に反復し、生産にリリースしたい追加機能ごとに進めることができます。

全体の仕組み

「ビルド、テスト、デプロイ」という言葉は、DevOpsを議論する際によく耳にする一般的な言葉のセットです。組み込みシステムでは、私たちも同じことを行います。なぜなら、私たちのデプロイメントも製造（そして最終的な顧客）に向けて行われるからです。プロジェクトのリポジトリでは、組み込みDevOpsのエンドツーエンドのワークフローを推進するためにGitlab CIを使用しています。私たちは「パイプライン」と呼ばれるものを使用して、ソフトウェアのコンパイル、ターゲット上でのテストの実行、または公式パッケージとしてのリリースなど、特定のタスクを達成するジョブを作成します。Gitlabでは、パイプラインはこのような順序で実行されるジョブの集合です：

図1: GitlabのATmega328P DevOpsワークフローで使用されるパイプラインの例

CIスクリプト（.gitlab-ci.ymlファイル）の内訳を示して、これがどのように機能するかのアイデアを提供します。

• Docker: ハードウェアインザループテストのためのビルドおよびランタイム環境のコンテナ化で議論されているように、この段階ではDockerイメージをビルドして、コードのビルド、テスト、フラッシュのための一貫した環境を作成します。これにより、異なるマシンやアーキテクチャ（デスクトップPC対ラズベリーパイなど）でビルドプロセスを再現可能にします。
• Test: この段階では、ユニットテストを実行して、コードが意図した通りの動作をしていることを検証します。自動テストは速く、既存のコードを変更またはリファクタリングする際に重要です。
• Build: この段階では、ソースコードをバイナリにコンパイルします。このプロジェクトでは、.elfファイルや.hexファイルのようなアーティファクトを生成し、それらをATmega328Pチップにフラッシュするために使用します。
• HIL (Hardware-in-the-Loop): この段階では、実際のハードウェア上でソフトウェアをテストして、実世界の条件で正しく動作することを確認します。これは、ハードウェアにソフトウェアをロードし、設計した機能が最終製品で実際に機能するかを検証するためのテストを実行します。
• Deploy: この段階では、ビルドされたアーティファクトをパッケージレジストリに公開し、使用可能にすることを扱います。
• Release: この段階では、新しいソフトウェアリリースを作成し、迅速かつ信頼性の高いアップデートを保証するために配信プロセスを自動化します。これは、製品の全組み立てに必要なソフトウェアのバージョンを取得するために、製造チームが使用するものです。

細部

いくつかの細かい詳細が、このワークフローを基本的なDevOps実装から、スムーズに動作し、よく文書化され、容易に観察可能なシステムに変えます。CIワークフロー内のいくつかの微妙な詳細が重要です。

• セマンティックバージョニング: 自動メカニズムを介して、または手動でバージョンを設定することは、特に生産を扱う際にリリースサイクルにとって非常に重要です。例として、これはCIスクリプト内の変数として設定され、その後、公開およびリリースジョブで使用されます。
• Dockerビルドロジック: Dockerコンテナビルドに使用されるロジックのブロックがあることに気付くでしょう：

if [ "$CI_COMMIT_REF_SLUG" == "$CI_DEFAULT_BRANCH" ]; then

  export IMAGE_TAG=$CI_REGISTRY_IMAGE/$IMAGE_TYPE:latest

else

  export IMAGE_TAG=$CI_REGISTRY_IMAGE/$IMAGE_TYPE:$CI_COMMIT_REF_SLUG

fi

このロジックは、「latest」タグをメインブランチ（つまり、マージリクエストが成功した後）にビルドされたDockerイメージのみを使用するように設定します。これにより、成功したマージリクエストのみが、誰もがそしてすべてのパイプラインがプルする最新かつ最高のdockerイメージを公開することを保証します。

• レポートとカバレッジ：Gitlabのような現代のCIシステムでは、マージリクエストやパイプライン内でテストとカバレッジレポートを抽出して表示することができます。例えば、このマージリクエストではコードカバレッジをキャプチャしました：

図2: マージリクエスト内のコードカバレッジ

このスクリーンショットでは、Gitlabがハードウェアインザループを使用してターゲット上で実行されたテストを要約しています：

図3: ターゲット上で実行されたテストの要約

最終的に、コードがユニットテストとターゲット上での検証を経た後、公開とリリースのステージは、生産チームが利用できる素晴らしいパッケージを生成します：

図4: ソフトウェアパッケージのリリース

これらの自動化されたステップにより、アジャイルな方法で新機能を反復的にリリースすることができます。多くの機能を開発し、それらをQA部門に送り、その後生産チームによるパッケージリリースのレビューを行う必要はありません。ここでのすべては単一のワークフローで発生し、完全に自動化されています。

結論

この記事では、DevOpsとアジャイル手法を組み込みシステム開発にどのように適用できるかを探求しました。具体的には、ATmega328Pマイクロコントローラを使用しています。GitlabでCIワークフローを実装することの利点について議論しました。これには、自動化、ビルド時間の短縮、効率的なテストが含まれます。CIスクリプトを分解し、各ステージを説明することで、効率と製品品質を向上させる堅牢で合理化された開発プロセスを作成する方法を示しました。この実践ガイド（およびリポジトリ内のソースコード）に従えば、独自の組み込みDevOpsワークフローを設定することもできるはずです。

プロジェクトのソースコードはこちらで見つけることができます：https://gitlab.com/embedded-designs/atmega328p-serial-led-control。