meideru blog

家電メーカーで働いているmeideruのブログです。主に技術系・ガジェット系の話を書いています。

【組み込み開発】自分の会社の開発環境を紹介する

 

オシロスコープ

現在、組み込み開発の仕事に従事しています。

入社前、疑問に思っていたことがあります。

それは

「実際の現場での組み込み開発の開発環境ってどんな感じなんだろう」

ということです。

当時、学生だった私には、実際の現場での開発環境が、どんなものなのか全く想像ができませんでした。学生レベルだと、せいぜいArduinoのSketchで数百行のコードを書く程度ですからね、、、

入社して、開発環境を知ったときの率直な感想は「想像以上に金かけてるなw」ということでした。

今日は、私の会社の組み込み開発の開発環境について、紹介したいと思います。

※機密情報を公開しないようにするため、多少、大雑把に書いているところもありますので、ご了承ください。

目次

現在の仕事について

大手メーカーで組み込みエンジニアをしております。

どのような製品の開発に携わっているかということについては、秘密とさせてください > <

大雑把に言うと、世界中のクリエイターが使用する製品です。一般ユーザーが使用することは、まずないと思います。

meideru blogは、匿名で運用しているので、身バレに繋がりそうなことは、非公開としております。すみません > <

プロフィール
ブログを閲覧していただきましてありがとうございます。簡単にmeideruのプロフィールを紹介しようと思います。プロフィール(2022年1月現在)名前:meideru性別:男年齢:28歳所在地:関東圏の某所職業:大手家電メーカーの組み込みエンジニア趣味:プログラミング、電子工作、映画鑑賞など将来の夢:起業して会社を作ること備考:カメレオンのアイコンは私が書きましたw経歴公立中学校入学・卒業公立高校入学・卒業私立大学入学・卒業家電メーカーに就職 ← イマココ中学時代中学時代は、勉強と部活(剣道部)に打ち込んでいました。授...

私の会社の組み込み開発の開発環境について

複数のリポジトリをrepoを使って管理

repo自体、あまり馴染みがない人も多いのではないかと思います。実際、会社に入社する前、聞いたことすらありませんでした。そして、Google先生に「repo」で聞いてみても、一発では、有用なページを紹介してくれないように感じます。

repoは、複数のGitリポジトリを管理できるツールのことで、Androidの開発などで使用されています。

※Androidの開発というのは、Androidのアプリの開発、という意味ではなく、Androidそのものの開発という意味です。

 

下記が、repoのイメージ図です。repoについて大規模開発になると、1つのリポジトリでではなく、複数のリポジトリに分割して開発を行います。1つのリポジトリを数百人で開発、なんて考えただけでもゾッとします。

一般的には、機能単位で分割することが多いです。私の会社だと「映像出力の機能A」「映像週力の機能B」…「音声コーデック機能A」「音声コーデックの機能B」… 「UI機能A」「UI機能B」…のような要領でリポジトリを分割しています。基本的には、リポジトリ単位で開発チームが存在しています。これらのリポジトリのコードをすべて参照してビルドを行うと、組み込み機器のファームウェアが出来上がります。

manifest.xmlには、どのリポジトリのどの状態を取得するのか、という情報が書かれています。状態を示す方法としては、リビジョン番号(コミット番号)を記すような方法もあるようですが、私の会社では、タグで判断する方法を採用しています。

manifest.xmlに書かれている情報を元に、各リポジトリのコードを取得します。そして、取得できたコードをベースに開発を進めます。

簡単な説明で恐縮ですが、以上が、repoの説明です。

詳しく知りたい人は、下記のページをご覧ください。

Repo - Qiita
複数の git レポジトリを管理する repo というツール https://gerrit.googlesource.com/git-repo/ について調べた。Android や Automotive Grade Linux (A...

ファームウェアのリリースサイクルについて

ファームウェアのリリースサイクルについて

Jenkinsがデイリーでビルドを行い、ファームウェアを作成します。コードを書き変え、タグを張り替えると、翌日出来上がるファームウェアには、前日書き換えたコードの修正内容が反映されているということになります。

毎日作成されるファームウェアは、社内の開発者用のウェブページからダウンロードすることができます。

余談ですが、ビルドが通らないようなコードにリリースタグを貼って、Jenkinsビルドを失敗させたりすると、プロジェクトリーダーにメチャクチャで怒られますw

評価のサイクルについて

品質評価のサイクルについて

Jenkinsがデイリーで作成するファームウェアを、評価チーム(QA)が、毎日評価します。半分くらいはテストが自動化されていますが、実際に実機で確認するために、手動で行う評価もあります。

無事、RC/GMを迎えられるように、グラフで可視化して品質を監視します。デグレを引き起こした開発チームには、修正を依頼したりします。

開発環境について

開発環境について

物理的な開発環境は、大雑把に言うと、上記のような感じです。

当たり前ですが、コーディングはローカルPCで行います。

ビルドは、AWSで運用されているビルドサーバーで行います。ローカルでビルドすることはできません。ビルド環境を整えるのが大変なので、開発環境運用チームが、用意しているビルドサーバーを使用します。

ビルドサーバーは、基本的に開発者1人に対して1台割り当てられています。月に数百万円単位で費用がかかっているようです。

ホスティングサービスは、皆さんおなじみのGitHubを使っています。

最終的な確認は、開発用基板にファームウェアを書き込んで行います。USB接続で書き込めますが、セキュリティ上の観点から、特殊なソフトを経由しなければ書き込めないようになっています。誰でも書き込めたら、ハックされちゃいますからねw

皆さんの開発環境はどうなっていますか?

以上が、私の開発の開発環境になります。途中、かなり端折っているので、抽象的な部分もあるかと思います。

皆さんの会社の組み込み開発の開発環境は、どうなっていますか?

私は、今の会社以外のことを知らないので、よそのことがとてもとても気になります(-.-;)

特に気になるのは、私の会社はビルドサーバーを使用している点です。

ビルド環境を構築するのが大変だから、一元的に用意されたビルドサーバーを使用しているということになっています。

しかし、今の時代、Dockerなどを駆使すれば、ローカル環境でも簡単に共通のビルド環境が構築できるのでは?と思うことがあります。

皆さんの会社の開発環境はどうなっていますか?

 - 技術系