継続的な統合-毎回デバッグとリリースをビルドしますか？

各プロジェクトのデバッグおよびリリースバージョンをビルドするために継続的インテグレーションサーバーを設定するときの標準的な方法ですか？ほとんどの場合、開発者はデバッグモードのプロジェクト構成セットを有効にしてコードを記述し、異なるライブラリパス構成、コンパイラー定義、またはデバッグ/リリース間で異なるように構成された他の項目があり、それらが異なる動作をする可能性があります。

各プロジェクトのデバッグとリリースの両方をビルドするようにCIサーバーを構成しましたが、考えすぎているのではないかと思います。私の仮定は、迅速なフィードバックを得ることができる限りこれを行うことであり、それが発生したら、おそらくリリースを夜間ビルドにプッシュします。これにアプローチするための「標準的な」方法はありますか？

両方の構成を構築しても問題はありませんが、（特にビルド時間の制約があるため）選択する必要がある場合は、リリース構成を構築します。

最終的には、顧客が使用する構成を構築、テスト、パッケージ化、および展開し、顧客が実行する前に構成に関する問題を発見する必要があります。

リリースのみ。

とにかく開発者がデバッグビルドを行っており、最悪のバグは「デバッグで機能する」バグであると想定します。それらをすばやく見つけて、みんなを幸せにする可能性のある変更を絞り込むことができます！

一晩でできれば両方をビルドしてテストすることを強くお勧めします。

• いくつかのheisenbugsを検出するかもしれません
• クライアントがテストおよび検証した動作を確実に取得できる

あなたはしばらくの間誰にも試されない可能性があるすべてのものを構築するべきです。つまり、ビルドターゲットが1つしかない場合、開発者はすぐに気付くので、継続的インテグレーションでデバッグを実行する必要はありません。しかし、多くの場合、複数のコンポーネントがあり、現在作業されていないコンポーネントは開発者によってビルドされませんが、一般的なコードの変更によって依然として壊れている可能性があります。このような場合、すべての構成をビルドする必要があるため、そのようなコンポーネントに触れる必要があるときにビルドが壊れることはありません。

すべての構成ですべてをビルドするのには時間がかかることが多いため、コミットのたびにすべてをビルドすることはできません。そのような場合は、最も重要なコンポーネントのリリース構成を毎回行い、すべての夜間ビルドを追加します。

私は現在プロジェクトに取り組んでいます。継続的なビルドがあり、バージョンコントロールを10分ごとにポーリングします。選択したばかりの構成でも、大きなコミット後は1時間以上かかる場合があります。すべての構成ですべてのコンポーネントをビルドし、常にクリーンなビルドを行う夜間ビルドよりも約5時間かかります。また、毎週のビルドよりも、カスタマイズされたすべてのバリアントでリリースをビルドするため、丸一日以上かかります。

それはあなたのプロジェクトに依存します。私の現在のプロジェクトでは、「デプロイメントビルド」の一部としてリリースバージョンをビルドしている間、コミットごとにデバッグ（およびユニットテストの実行）のみをビルドしています。

私が働いていた最後の会社では、リリースバージョンが少し異なる動作をするいくつかの問題があったため、すべてのコミットでデバッグとリリースをビルドし、両方でユニットテストを実行しました。