リリースビルドとナイトリービルド

典型的な解決策は、ビルドサーバーで実行されているCI（継続的インテグレーション）ビルドを使用することです。これは、ソースコードの分析、ビルドの実行（デバッグ）、テストの実行、テストカバレッジの測定などを行います。

現在、通常知られている別のビルドタイプは「ナイトリービルド」です。コードドキュメントの作成、セットアップパッケージの作成、テスト環境への展開、テスト環境に対する自動（スモークまたは受け入れ）テストの実行などの遅い処理を行います。

さて、質問：

• リリースビルドとして3つ目の別個の「リリースビルド」を使用する方が良いですか？
• または、リリースモードで「Nightly build」を行い、リリースとして使用しますか？

会社で何を使用していますか？

（リリースビルドでは、潜在的な製品バージョンのソース管理に何らかのタグを追加する必要もあります。）

リリースビルドをナイトリービルドと同じにする場合は、リリースするものとまったく同じものをテストする必要があります。開発テストですでに検出されている可能性のある本番環境のバグを発見したくありません。

リリースビルドとナイトリービルドの違い：

• ナイトリービルドは毎晩自動的に実行されますが、リリースビルドは特定の時点で手動で実行する必要があります
• リリースビルドは、理想的にはソースコードにタグ付け/ブランチし、ビルドアーチファクトを中央レポに展開する必要があります（Mavenを使用する場合など）

これらの違いは、実際には、私が知っているほとんどのビルド管理システムのいくつかの追加オプションです。人的エラーの可能性を最小限に抑えるために、これらは、たとえば必要なパラメータのみを取得する（および検証する）バッチ/スクリプトファイルに保存できます。

さて、私はリリースビルドを可能な限り夜間に近いプロセスにしたいと思います！理想的にはまったく同じですが、タグが付いています。

問題は、リリースビルドと夜間のビルドが同じでない場合、異なるものが問題を隠してしまう可能性があることです（または、追跡をより困難にすることができます）。

CIサービスによって実行されるすべてのチェックインをすべてビルドする1つのビルドプロセスがあります。それはデバッグビルドとリリースビルドの両方になります。

2つまたは3つの個別のプロセスを用意することは、文書化せずにランダムに変更を開始することを要求するだけです。誰かがドアから出る準備をするために、潜在的なリリースごとに15ステップを実行する必要があることに気付くのはそう長くはかからないでしょう。

私がやりたいことの1つは、ナイトリービルドをデバッグモードではなくリリースモードにすることです。System.Diagnostics.Debugを置き換えるlog4netなどのロギングフレームワークでは、リリースモードとデバッグモードの主な違いはオブジェクトの有効期間とコードの最適化です。

実際にデバッガをナイトリービルドにアタッチする場合を除き、これも行うことをお勧めします。

私たちが従うプロセスは、毎晩のビルドが毎晩実行され、それが機能する場合は、同じビルドを他のサーバーにデプロイできます（再構築せず、パッケージ化されたインストーラーを使用して実行するだけです）。ナイトリービルドに問題がある場合は、ブランチで変更をチェックインし、日中にそのブランチで「ナイトリー」ビルドを実行します。その後、テストを再実行できます。