「デバッグ」ビルドと「リリース」ビルドを分離しますか？

https://stackoverflow.com/questions/420343

05-07-2019
|

質問

開発者が実際にテストしたソフトウェアのバージョンをリリースする方が良いと思います。そのため、プロジェクト/メイクファイルから「デバッグ」ターゲットを削除する傾向があるため、ビルド（およびテスト、デバッグ、およびリリース）できるバージョンは1つだけです。

同様の理由で、「アサーション」を使用しません（常にアサーションも参照してください）悪い？ ...）。

ある人は、「デバッグ」バージョンの理由はデバッグしやすいことだと主張しましたが、最終的にはリリースしたものをサポートしてデバッグしたいので、ビルドする必要があると反論しました必要に応じてデバッグできるデバッグ...これは、デバッグシンボルを有効にし、「リリース」ビルドでも最適化を無効にすることを意味する場合があります。

他の誰かが「これはそんなに悪い考えだ」と言った。それは私が数年前に進化させたポリシーであり、次のように焼き付けられました：

一部の開発者はリリースバージョンではなくデバッグをテストしています
一部の開発者は、リリースバージョンにのみ表示されるバグを記述しています
不十分なテスト後にリリースバージョンをリリースしている（これまで完全に適切ですか？）
リリースバージョンをデバッグするために呼び出される

その後、このプラクティスに従う他の複数の開発ショップを見てきました（つまり、個別のデバッグビルドとリリースビルドはありません）。

あなたのポリシーは何ですか？

解決

これはマイナーかもしれませんが、他の人がここで言ったことになります。 QAテストリリースビルドを使用する利点の1つは、QAで問題が発生する理由を把握する必要がある開発者のニーズにより、ソフトウェアの組み込みのデバッグおよびログ機能が徐々に向上することです。

開発者がリリースビルドをデバッグする必要があるほど、顧客が問題を抱え始めたときに、より優れたツールを使用できます。もちろん、開発者が開発サイクルの一部としてリリースビルドに取り組む理由はありません。

また、バージョンのテスト期間の途中でデバッグからリリースビルドにQAを切り替えるオーバーヘッドを許容するのに十分なサイクルを持っているソフトウェア会社も知りません。完全なQAサイクルを実行することは、非常にまれにしか発生しないことです。

他のヒント

デバッグビルドとリリースビルドを別々にすることは、開発を容易にするため、良いアイデアです。

ただし、デバッグビルドは開発用であり、テスト用ではありません。リリースビルドのみをテストします。また、開発者を使用してこれらのビルドをテストするのではなく、テスターを使用します。

これは、IMOの両方の長所を提供する単純なポリシーです。

編集：コメントへの応答で、デバッグビルドとリリースビルドが異なるコードを生成する（できる）ことは明らかだと思います。「-DDEBUG」を考えてください; vs.＆quot; -DNDEBUG＆quot;、＆quot; #if defined（DEBUG）＆quot;など。

したがって、出荷するコードをテストすることが重要です。デバッグビルドとリリースビルドで異なるコードを実行する場合、同じ人がテストしたかどうかに関係なく、2回テストすることになります。

ただし、デバッグシンボルはそれほど大きな問題ではありません。常にデバッグシンボルを使用してビルドし、ストリップされていないバイナリのコピーを保持しますが、ストリップされたバイナリをリリースします。各バイナリにビルド番号を何らかの方法でタグ付けしている限り、どのストリップされていないバイナリが、デバッグする必要があるストリップされたバイナリに対応するかを常に識別できるはずです...

外部ソースからデバッガでバイナリを削除してシンボルをロードする方法は、プラットフォームに依存します。

当社のポリシーでは、開発者にデバッグビルドの作業を行わせることをお勧めしていますが、リリースバージョンは他のすべてのユーザー（QA、BA、セールスなど）が実行します。昨日、私はリリースビルドでしか現れなかったバグを修正しなければなりませんでした。単にリリースでしか現れなかったので、何が起こっているのか明らかでした

この店では初めての店で、私はここに18ヶ月ほど来ました。

問題が発生するのは、リリースビルドがデバッグビルドと異なることを行う場合です-はい、私は地獄に行って、これを非常に古い、非常に丸い生産コードで見ました。

構成間の唯一の違いがデバッグシンボルと最適化である場合、両方を持たない理由はありません。

そのため、リリースをビルドする必要があります必要に応じてデバッグできます...これデバッグシンボルを有効にすることを意味する場合があります。でも、いくつかの最適化を無効にします「リリース」ビルド。

うーん...あなたは私にデバッグビルドをしているように聞こえます...そうですか？

間違いを犯した部分は次のステートメントです：

リリースする方が良いと思うソフトウェアのバージョン実際にテストした開発者

開発者はコードをテストしません。テストコードをテストします。

ユニットテストでは、 ALL ビルド構成をテストする必要があります。開発者を、片手で背中を縛って作業させないでください-自由に使えるすべてのデバッグツールを使用してください。デバッグビルドはこれらの1つです。

アサーションについて：アサーションの使用は、契約によってプログラミングするかどうかに大きく依存します。その場合、アサーションはデバッグビルドでコントラクトをチェックするだけです。

リンクされたスレッドでの私の答えによると、非常によく似た理由でデバッグとリリースにも同じビルドを使用しています。アルゴリズムレベルでの手動最適化と比較した場合、オプティマイザーによる10％〜20％のパフォーマンス向上は非常に小さい傾向があります。 1つのビルドで多くの潜在的なバグが削除されます。具体的には、

初期化されていない変数と小さなバッファオーバーフローは、デバッグと最適化されたリリースビルドで非常に異なる結果になる可能性があります。
シンボリック情報が利用可能であっても、オブジェクトがソースと一致しないため、最適化されたリリースのデバッグは困難な場合があります。変数が最適化され、コードが再配置された可能性があります。したがって、テスト済みのリリースビルドで報告されたバグを追跡するのはより困難であり、したがって時間がかかる可能性があります。

自動リグレッションテストで最適化されていないビルドと最適化されたビルドを比較した場合、最適化によって得られるパフォーマンスの向上は、私の場合は2つのビルドを持つほどの付加価値はありません。私が開発するソフトウェアはCPUを非常に多く消費する（たとえば、大きなサーフェスモデルを作成して操作する）ことに注意する価値があります。

Javaを使用して開発する場合、非デバッグバージョンは嫌いです。例外がスローされると、バグを追跡するのが難しくなる、または不可能になるような行情報が得られません。また、デバッグと非デバッグの実行時の違いはJava 5以降では約5％であるため、これは実際には問題ではなく、現在のハードディスクではサイズは問題ではありません。

デバッグバージョンを使用するプラス側：

スタックトレースには、必要なすべての情報が含まれています
変数を調べることができます
実稼働環境で問題が発生した場合は、デバッグバージョンをインストールするために最初にサーバーを停止することなく、実行中のプロセスに単純に接続できます。
巧妙な最適化のバグに巻き込まれることはありません
ビルドはより単純です（1つのアーティファクトのみ）

開発者はデバッグビルドを使用し、QAおよびその他すべてのユーザーがリリースバージョンを使用します。これを「本番」と呼びます。これの主な利点は、デバッグビルドで、多くのコードとアサーションを追加できることです。一部のオブジェクトには、デバッガーでコードを表示する場合を除いて使用できない余分な情報が含まれています。一部のオブジェクトは、定期的に自分自身を検証して、すべての状態情報が一貫していることを確認します。これらのことにより、デバッグバージョンの処理速度は大幅に低下しますが、実稼働ビルドで見つかるはずのバグの終わりを見つけるのに役立ちました。

私が言ったように、QAおよびパフォーマンステストはすべて実稼働ビルドを使用しており、実稼働では表示されるがデバッグでは表示されない問題が発生することがあります。しかし、それらは比較的まれであり、開発者としては、実稼働ビルドではなくデバッグビルドをデバッグする利点がその問題をはるかに上回っています。

プロジェクトのサイズと、使用しているビルドシステムとテストの種類に依存すると思います。

自動ビルドシステムがあり、特定のビルドで単体テストと機能テストを簡単に実行できる場合、複数のビルドタイプで問題が発生することはありません。

「デバッグするものを出荷する」には常に登録しているので、出荷するものをデバッグできます」質問に記載したすべての理由により、アプローチします。

私の意見では、この議論には非常に重要な点が欠けています：

それは、プロジェクトの種類に依存します！

ネイティブ（C / C ++）プロジェクトを作成すると、コンパイラの最適化によってデバッグがほぼ不可能になる場合があるため、実際にはデバッグビルドを作成する必要があります。

Webアプリケーションを作成する場合は、実行中にログ機能を有効にできる1つのビルド（一部のWebアプリケーションにとっては「ビルド」はかなり誤解を招くものですが）を使用したい場合があります。

ネイティブのC ++プロジェクトとPHP Webアプリケーションは、明らかにすべての種類のプロジェクトではありませんが、私の主張が伝わることを願っています。

P.S .: C＃向けに開発する場合、デバッグビルドを使用するとコンパイラの最適化が無効になりますが、私の経験では、C ++とほぼ同じくらいの違いに遭遇することはないため、境界ケースに遭遇します

ここでは、デバッグモードで開発し、リリースモードですべてのユニットテストを行います。私たちは、クラシックASP、ASP.Net、VB.Net、およびC＃に至るまでサポートするための少数（12未満）のアプリケーションを備えた小さなショップです。また、すべてのテストを処理する専任の担当者がおり、デバッグされた問題は開発者に返されます。

私たちは常に両方を構築しますが、そうしないことさえ考えません。デバッグオプションを有効にすると、コードサイズが増加し、パフォーマンスが低下します。テスト時のソフトウェアの種類ではなく、顧客がコードと5つの他のアプリを実行している場合はどうでしょうか。

テストの問題は自動化されたテストを使用して整理できるため、リリースの準備ができていると思われるときにリリースビルドを簡単にテストできます。開発者または会社がリリースビルドを適切にテストできないことは、リリースおよびデバッグビルドのアイデアの失敗ではなく、開発者または会社の失敗です。

最後の点で、リリースビルドをデバッグすることを求められたことはありません。修正するだけです...

これはトレードオフです。 CPUサイクルは安く、人間のサイクルは高価なままですが、より安くなっていることを考えると、大きく複雑なプログラムの単一バージョン（debug（gable）バージョン）のみを維持することは非常に理にかなっています。

アサーションを常に使用することは、アサーションを使用しないよりも常に安全なポリシーです。デバッグバージョンとリリースバージョンを別々に作成する場合は、リリースバージョンでもアサーションが有効になっていることを保証するために必要な #define dシンボルを再度有効にします。

トレードオフは簡単だと思います。はい、リリースビルドのみで、実際に出荷されているものを実際にテストします。一方で、開発者のデバッグの容易さやユーザーのパフォーマンスの代価を払うので、両方のケースをチェックするのはあなた次第です。

ほとんどの中規模から大規模のプロジェクトでは、デバッグが容易であることにより、最終的にユーザーにとってより良い製品が保証されます。

こちらをご覧ください最も物議をかもしているプログラミングの意見は何ですか

引用：

意見：これまでにないことはありません   ＆quot; debug＆quot;の間のコードおよび「リリース」   ビルド

そのリリースが主な理由   コードはほとんどテストされません。より良い   テストで同じコードを実行する   そのままです。

「デバッグターゲット」を削除することにより、開発者にソフトウェアのリリースバージョンでのデバッグを強制することになります。実際にそれが意味することは、次の2つのことです。

1）＆quot;リリースビルド＆quot;最適化が無効になります（そうでない場合、開発者はデバッガーを使用できません）

2）ビルドには、実行を変更する特別なPREPROCESSORマクロがありません。

つまり、実際に行うのは、「デバッグ」だけを削除するのではなく、リリースとデバッグの構成をマージすることです。モード。

私は個人的に、悪影響なしでiOS開発でこれを行いました。記述されたコードで費やされた時間は実際に起こっていることの1％未満であるため、最適化は重要な貢献者ではありませんでした。この場合、彼らは本当にバグの増加を引き起こすように見えましたが、そうしなかったとしても、1つの方法でテストし、異なるコードでQAに与えるという考えは、問題で考慮するためのもう1つの要因をもたらします。

一方、最適化が必要な場合、それらが有用である場合、および両方をテストするのに十分な時間がある場合でさえあります。通常、デバッグとリリースの間の変更は非常に小さいため、誰にもまったく問題は発生しません。

ものを完全にテストするために頼ることができる本当のQAグループがあれば、リリースに近づくまでデバッグビルドを作成し、完全なQAサイクルがドアから出る同じビルド。

少なくとも1つのケースでは、デバッグコードがまだ残っているものをリリースしました。唯一の結果は、ほんの少し遅くなり、ログファイルが非常に大きくなったことです。

私の会社には、デバッグとリリースの両方があります。 -開発者はデバッグバージョンを使用して、バグを適切に見つけて修正します。 -TDDを使用しているため、サーバー上で実行する大きなテストスイートを使用して、デバッグとリリースの両方のビルド構成と、64/32ビルドもテストします。

したがって、「デバッグ」を使用する場合は、構成は、開発者がバグをより迅速に見つけるのに役立ちます。バグを使用しない理由はありません。 1つ。

リリースバージョンをデバッグできるように、.PDBファイルを使用してリリースバージョンをビルドすることをずっと前に学びました。多くのプログラマーが忘れがちなのは、すべての最適化をオフにしてデバッグバージョンを実行すると、まったく異なるプログラムをデバッグしていることです。（ほとんどの部分で）リリースビルドのように動作しますが、それでもリリースビルドとは異なるプログラムです。

さらに、リリースビルドのデバッグはそれほど難しくありません。クラッシュダンプを取得した場合は、とにかくそれを実行できる必要があります。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow