私は、プログラミングにC/C++を使用する組み込みの世界から来て、IDEを使用してバイナリファイルを生成し、それをハードウェアボードにプログラムして、テストすることができます。
この背景で、自動ビルドの現在のワークフローである-build(IDEを使用)-> Flashからハードウェアへのテスト->テストよりも優れたワークフローは何ですか。つまり、私が運用しているドメインでCIの利点を活用できる方法はありますか?
組み込みソフトウェアの場合、継続的インテグレーションが役立ちます
最初のケースでは、シミュレーションターゲットのビルドを定期的に作成し、そのシミュレートされたターゲットでテストを自動的に実行するCIサーバーをセットアップできます。 2番目のケースでは、実際のターゲットをCIサーバーにフックし、定期的にビルドを作成してテストする必要があります。
両方の場合の利点は、自動化された無人の回帰テストを取得できることです。これは、ソフトウェアの見かけ上関連のない部分(手動テストでは触れなかった)であっても、誤って何かを壊したことを示します。 。
組み込みチームでCIを使用する理由は無数にあります(IDEで単独で作業している場合、CIの利点はそれほど明白ではありません。CIでの統合は統合であり、単独で作業しているときは誰とも統合していません)
これにより、再現可能なスクリプト化された自動ビルドプロセスが必要になります。 CIシステムからの出力は、テストされ、一貫性のある出力です。どの開発者がマシンにインストールしても、ビルドは影響を受けません。
CIの大きな利点は、自動化された単体テストを実行できることです。これらのテストは、CIマシンプラットフォームにクロスコンパイルできます。これには、ハードウェアに依存するロジックを残りの部分から切り離し、最終的に別のプラットフォームへのポートを解放し、プラットフォームに依存しないコードを別のプロジェクトに再利用しやすくするというアーキテクチャ上の副作用があります。
それは、ソースコントロールビルドへの全員のコミットが確実にビルドされ、そうでない場合はすぐにフィードバックを提供します。これは、どのコミットがビルドを壊したかを知ることを本当にスピードアップします。
これにより、テストチームは、開発チームに負担をかけることなく、最新バージョンを入手するための共通の場所を確保できます。または、2週間前から出現した新たに発見されたバグをすばやく二分するために...
自動化されたコード検査、メトリック、および分析ツールは、チェックインされたコードに対して警告をトリガーすることができます。
通常のワークフローでは、通常、サーバーでビルド製品を使用できるようにし、ボードでフラッシュします。日常の開発では、IDEのビルド/フラッシュワークフローを使用します。私はあなたのプロジェクトについては知りませんが、自動スクリプトを使用して、実際のボードで新しいファームウェアをフラッシュし、たとえばシリアルインターフェイスを介してボードでテストを自動的に開始/停止することもできます。