私たちはCI環境で作業しており、EnterpriseCruiseがビルドを実行しています。開発者は全員、ビルドが壊れた場合に通知するためにCCTrayをローカルにインストールしています。
CCTrayには、ビルドを修正することをチームに知らせるために使用できるビルドを修正するためのメニューオプションVolunteerがあります。ただし、これは私たちの環境では機能しません（理由：HTTP経由で監視されているプロジェクトで現在サポートされていないビルドを修正してください）。
だから問題は-誰かが壊れたビルドを修正していることを誰かが示すことを可能にする彼らのチームで使用するテクニックを持っている人はいますか？
私にとって、継続的インテグレーションはツールだけでなく、プラクティスでもあります。その一つが責任です。言い換えれば、ビルドを壊す人は、それを修正する人でもあります!
「私はそれを取ります」を撮影するのが私の好みです。（責任ロメインタズに加えて説明）
開発者のメーリング リストに電子メールを送信して、ビルド ブレークの所有権を取得していることを全員に知らせます。
私たちは同じ場所にいて、全員で cctray を実行しており、ビルドが壊れると音声アラート (スターシップ エンタープライズからの赤いアラート) が鳴ります。それが壊れたとき、私たちは皆、「誰がビルドを壊したのか」と叫びます! 誰がビルドを壊したかを突き止めたら、彼らが尻尾を脚の間に挟み込み、ばかげた恥ずかしい笑いをして、ビルドを修正することを志願するまで、彼らに嫌がらせをします。
ビルドとテストによって監視されていないものが CI ボックスで変更される可能性があることに注意してください。例: 誰かがボックスにアクセスして権限を変更したとします。その後、次のチェックインが行われると、チェックインを行った人がビルドを壊したように見えますが、実際には誰にも言わずに手動で変更を行った人でした。
ボランティアの場合、ツールは役に立ちますが、口頭での対面コミュニケーションは依然として王様です。
責任は通常、誰がチェックインでビルドを壊したかです。これは、異なる個人からの複数のチェックインであっても、明らかなことがよくあります。その後、ビルドが壊れたままであるかどうかについて少し交渉があります。特に科学的でも厳格でもありませんが、うまくいくようです。
ビルドが壊れた場合、CCtray には「Volunteer to fix the build」のオプションがあります。そして、ビルドを修正しているすべての開発者に自動的に通知します