どの時点でリリースビルドに切り替える必要がありますか？

Jez HumbleのContinuous Deliveryで設定されているプラ​​クティスの1つは、1つのパッケージをビルドしてから、展開先の各環境にリリースし、実稼働に移行する前に展開とアーティファクト自体が複数回テストされるようにすることです。

私はこの考えを完全に支持します。

一方、行番号付きのスタックトレースを提供するデバッグモードビルドは、リモートデバッグ機能と同様に、テスト環境で非常に便利です。しかし、リリースビルドを実稼働環境に送信する必要があります。

それでは、最初の原則に従う人々にとって、どの時点でデバッグからリリースビルドに切り替えるのですか？

テスト環境への最初の展開の前に、デバッグモードを失うコストを計算することは、実際のリリース候補を早期にテストするために支払う価値がありますか？または、プロモーションプロセスのある時点で、ソフトウェアを介したビルドプロセスを信頼することを考えて、再度ビルドしますか？それとも、すべてを台無しにして、デバッグバージョンを運用環境に展開するだけですか？

注：通常、ビルド時にスイッチを設定するのではなく、設定でスイッチをフリックできるため、これはインタープリター言語には実際には適用されません。

それでは、最初の原則に従う人々にとって、どの時点でデバッグからリリースビルドに切り替えるのですか？

ソースコードがバージョン番号を取得し、Debianビルドキューにプッシュされたときに、早めに切り替えます。ただし、入出力を適切に指定し、システムとのやり取りがほとんどない科学ソフトウェアを実行するという幸運な状況にあるため、エラー状況を再現するコストはかなり低くなっています。

これも私の一般的な答えです：ビルドを変更するポイントは、主にエラーの再現コストに依存します。これらが非常に高い場合、デバッグビルドを出荷して顧客をテストします。これには、実動ビルドのビルド失敗のリスクが伴いますが、テストケースの再現に数週間を費やすよりも、この方が安価です。

それでは、最初の原則に従う人々にとって、どの時点でデバッグからリリースビルドに切り替えるのですか？

QAに進むとすぐに、リリースビルドに切り替えます。しかし、リリースビルドをビルドするときは、ビルドプロセスによってDLLのデバッグバージョンもビルドされます。これにより、デバッグDLLをQA環境にすばやくドロップし、必要に応じて追加情報を取得できます。

dllのリリースバージョンとデバッグバージョンの両方がバックアップされ、数年間保持されます。

この環境では、コードは多くのサイトに展開されます。したがって、デプロイメントの各インスタンスに異なるコンテキストを適用する必要があります。通常、「リスクの少ない」重要な場所に展開し、その体験を確認します。

この展開はまだ実稼働中なので、これは「デバッグ」モードではありません。ただし、テストが適切に行われていることも前提としています。

もちろん、デバッグモードをオフにすると、（サイト上の）コードの迅速なデバッグが困難になる場合があります。しかし、リリースが失敗した場合、プロダクションはフォールバックリリースに切り替えます。

ただし、同じ環境を維持または作成し、そのような環境を再現して再度テストするようにします。（これは常に簡単なことではありませんが）必要なのは、トランザクション/入力を再現することだけです。

ポイントは、誘惑、デバッグモードのリリースがどれだけ本番環境にあるべきではないかです。しかし、これがルールだとは言いません。

もう1つのことは、リリースが（かなりの時間実行することによって）他の施設がまだ受け入れていないことを確立するまで、トライアルと呼ばれます。

ビルドプロセス自体に問題がないことを確認する方法は他にもいくつかあります。こちらをご覧ください： RAD環境でリリース品質を改善する簡単な方法

デバッグビルドをビルドするために、開発マシンをセットアップしています。しかし、開発者がコードをコミットすると、継続的統合環境（TeamCity）で展開パッケージが作成され、リリース用にビルドされます。したがって、QAにデプロイすることにしたときはいつでも、CIサーバーから最新のデプロイメントパッケージを取り出してプッシュするため、開発マシン上にない限り常にリリースされます。

ところで、一部の言語では、リリース用にビルドする場合でも、デバッグシンボルを作成できます。たとえば、.NETには、最適化を許可するがデバッグファイルを作成する「pdbのみ」の設定があります。明らかに、リリースバージョンに対するデバッグは、行ごとに同等ではないため、扱いにくいですが、ピンチで役立つ場合があります。