This これまで読んだ中で断然最高の説明です。
最も単純なのは、チェックインがリビジョン管理システム（CVSなど）に行われるたびにプロジェクトを再構築するメカニズムです。これは、CDイメージの生成、VM内へのマウント、製品のインストール、および完全なテストの実行に至るまで、テストの実行を含むように拡張できます。
これには、コードの変更によってシステムができるだけ早く壊れたときに強調表示するという単純な利点があります。コードの中断を検出するだけでなく、中断の原因を強調表示します。この心理的効果は、チェックイン前の適切なテストを促進するのに非常に効果的です。
これは、ソフトウェア開発プロセスのすべての側面が揃っていることを確認して、製品の動作バージョンを毎日作成できるようにすることです。エクストリームプログラミングの一部として最もよく知られています。
これには、ビルドの自動化、自動テスト、毎日のチェックイン、ソースコードリポジトリの使用など、さまざまなことが含まれます。ただし、最終的な目標は、プロジェクト全体をコアアジャイル原則に従って実行し、早期かつ頻繁に提供できるようにすることです。これにより、ユーザーなどからのフィードバックを活用できます。
ファウラーのページへのリンクは+1。
個人的には、単一のビルドを使用するという慣習が不十分だったために、何かがコンパイルされなかったときはいつでも知ることが「いい」と思いました（はい、本番ビルドで開発しました。素晴らしかったです）。私が去る前に、私たちは統合テストフェーズを持っていませんでした。
ただし、しばらくすると、コーディングの大幅な変更の量が減りました（「チェックインして、変更が競合しないように祈る」が横行していたのと比較して）。最終的に、ほとんどの開発者は、CC.Netトレイアイコンから確認を得るために、頻繁に小さな変更を加え始めました。
全体として、必要に応じてビルドをすぐに送信できることを知って非常に安心しました。いくつかのスモークテストを統合していたら、ストレスレベルはかなり低かったと思います。