展開エラーはビルドの失敗を構成する必要がありますか？
当社のソフトウェアは、製品が複雑なため、社内で作成された展開ソフトウェアを使用しています。現在のQA（開発ではない）ビルドプロセスの一部として（より多くの社内ソフトウェアを使用）、ビルドの前に、コードをコンパイルし、データベースにパッチを適用し、ソフトウェアをデプロイし、スモークテストを実行します。場合によっては自動UIテストを実行します。合格"。 TFS2010に移行し、社内のビルドプロセスを廃止します。このプロセスを、TFSビルドに追加する必要はありません。
展開を成功させ、開発チームにエラーを報告するために、どのプロセスを使用しますか？展開エラー/煙幕または自動UIテストの失敗が発生した場合、ビルドを失敗として分類する必要がありますか？
TFSは、ファイルがドロップフォルダーに配置されるとビルドプロセスを終了し、そのビルドをOKとしてマークします。現在と同じソリューションを使用する場合は、ビルドを成功としてマークする前に、TFSビルドを拡張してこれらすべてのタスクを実行するか、ビルドが以前に成功した後に失敗としてマークするメカニズムを用意する必要があります。 。
誰が問題を修正できるかということにもなると思います。チェックインできるanyoneが「デプロイメントのエラー」を修正できると期待される場合、通常のビルドは失敗するはずです。
それ以外の場合は、2つの「ビルド」を実行します。最初のビルドはコードをコンパイルし、単体テストを実行します。 2番目のビルドは、最初のビルドからの出力を取得してから、デプロイメントチェックを実行します。このようにして、デプロイメントシステムで機能しない通常のプログラマーは、インストールスクリプトを更新する必要がある方法で別のプログラマーがアプリを拡張した場合でも、機能し続けることができます。
ほとんどの人が適合できない問題に対してビルドに失敗すると、失敗したビルドが無視される傾向があります。
すべての開発者がメインビルドを修正するまで作業を停止することを望みます。これは、常に修正できる場合にのみ発生します。
ビルドが期待される出力を生成できない場合、それは壊れており、ビルドエンジンはそれを壊した人と知る必要のある他の人に通知する必要があります。
誰かが彼らに関係のないプロセスを壊すことができる場合、あなたはあなたのビルド方法論であなたが望むより強い依存関係を持っているかもしれません、そしてあなたはそれらを取り除くためにそれを調査したいかもしれません。
コンパイルまたはテストでエラーが発生すると、ビルドが失敗としてマークされます。
展開のエラーは、そうでない場合もあります。発生した場合に何をする必要があるかによって異なります。通常、エラーがある場合は、誰かが（修正）アクションを実行する必要があることを意味します。そうです、ビルドが失敗したとマークします。ビルドエラーとデプロイメントエラーを区別したい場合は警告で問題ないと思いますが、それはセマンティクスの問題だと思います。
重要なことは、通知が送信され、さらに重要なことに、読み取られるようにすることです。たとえば、件名のどこかに「失敗」または「失敗」がない限り、ビルドサーバーからのすべてのメールを直接ゴミ箱にダンプします。