ニュートラルビルド

ソフトウェア開発において、ニュートラル ビルドとは、開発者がソース コードバージョン管理システムにチェックインしたソース コードの現在の状態を反映し、ニュートラル環境 (開発に使用されていない環境) で実行されるソフトウェア ビルドです。

ナイトリー ビルドは、自動的に実行されるニュートラル ビルドです。通常、このビルドは、ビルド中にソース コードが変更されないように、オフィスで作業している人がいないときに実行されます。ビルドの結果は、到着したプログラマーによって検査されます。プログラマーは通常、ソース コードの最近の変更によってビルド プロセスやソフトウェアの機能が損なわれていないことを確認することを優先します。ナイトリー ビルドでは、システムの更新によってビルド ツールが損なわれていないことも確認されるため、ソース コードが変更されているかどうかに関係なく実行されることがよくあります。

対照的に、継続的インテグレーション環境では、変更がチェックインされるたびにプロジェクトが自動的に再構築され (多くの場合、1 日に数回)、より迅速なフィードバックが提供されます。ただし、夜間ビルドが必ずしも含まれるわけではありません。その結果、コンパイラとツールの更新により、古いプロジェクトを簡単にコンパイルできなくなる可能性があります (警告なし)。それでも、CI 手法はより現代的なアプローチと見なされています。CI ジョブは分離された仮想マシンで実行されることが多く、通常は自動テストも含まれます。

開発者が「ビルドを壊した」と言う場合、事実上、開発者がチェックインしたコードは、自分のアカウントではコンパイルされ (そしてうまくいけば適切に実行もされる) たかもしれないが、他の誰かのアカウントではコンパイルされない (したがって実行できない) と言っていることになります。これは通常、チェックインされなかった開発者固有の追加の変更、または (環境変数などの場合は)リビジョン管理下にないシステムへの変更が原因です。最も一般的なケースの 1 つは、変更されたすべてのファイルをチェックインすることを覚えているが、新しく作成されたファイルをリポジトリに追加し忘れることです。他の開発者が問題に気付かずに新しいコードをチェックアウトすると、問題が修正されるのを待つ間 (または自分で修正しようとするが、複数の開発者が同時に問題を修正しようとするとさらに問題になる可能性がある)、作業が停止する可能性があります。これは当然、生産性の大幅な低下につながります。

ニュートラル ビルドは、高負荷で短期間で実行されるソフトウェア開発プロセスにとって重要です(エクストリーム プログラミング、スタートアップを参照)。ニュートラル ビルドがないと、ソフトウェア品質保証部門用に作成する必要があるビルドでは、大幅な変更の途中である可能性のあるコードが使用されるため、独立した検証を目的としたビルド (特にリリースの可能性について評価されているビルド) からは除外するのが最善です。

信頼性の高い中立的なビルド プロセスを妨げる障害としては、次のようなものがあります。

• 一貫したビルド自動化システムとプロジェクト制御ファイルのセットを取得します。
• 開発マシンと同じオペレーティング システムとツールがセットアップされていること。
• すべてのファイルが最新であることを確認するチェックアウト手順を設定します。これには、バージョン管理システムをプロセスに統合するという追加タスクが必要になる場合があります。
• ビルド プロセスを特定のIDEから切り離します。
• 失敗したビルドを診断できるように、ビルド システムからの適切なフィードバックを設定します。
• 自動ビルドの利点を経営陣に納得させる。

次のリストは、ナイトリービルドやニュートラルビルドが公開されているソフトウェアの例を示しています。

• Arduino 、シングルボードマイクロコントローラのファミリー^[1]
• Atom 、主にコンピュータプログラミングに使用されるテキストエディタ^[2]
• CyanogenMod 、 Androidベースのデバイス用のカスタムROM ^[3]
• Firefox、ウェブブラウザ^[4]
• Media Player Classic、メディアプレーヤー^[5]
• MuseScore、楽譜作成プログラム^[6]
• RetroArch 、レトロビデオゲームコンソールのエミュレーター^[7]
• Simutrans、交通シミュレーター^[8]
• VLCメディアプレーヤー、オープンソースメディアプレーヤー^[9]
• WebKit 、AppleのSafariで使用されているウェブブラウザレンダラー^[10]

• デイリービルド