コードを毎晩ビルドする自動ビルド サーバーがあります。チームの全員がソース ツリー全体をビルドできるわけではないので、これは便利です。最近、チームの一部のメンバーは、ビルド エラーを迅速に修正することについて、より怠惰になりつつあります。ビルドが成功しないまま数週間が経過することもあります。ある開発者が、「ビルドは既に壊れている。今こそ [いくつかの重大な変更] を追加する良い機会だ」と言うのを耳にしました。私は最も下流のコードに取り組んでいるので、通常、ソース コード リポジトリとひどく同期していないツリーの部分を扱っています。これにより、変更を送信する前に変更をテストすることが非常に困難になります。
ナイトリー ビルドは継続的に壊れているため、ナイトリー ビルドの利点のほとんどを失っているように感じます。私はここでベースから離れていますか、それともビルドを修正することを優先する必要がありますか?
ナイトリー ビルドの修正は最優先事項です。おっしゃる通り、壊れたら何の価値もありません。破損の原因となるコードをチェックインしたい場合は、ブランチでこれを行い、テスト時にのみマージする必要があります。
これらの開発者は、明らかに元の状態に戻す必要があります。
チェックイン時ではないにしても、毎日少なくとも数回ビルドすることをお勧めします。そして、ビルドサイクルが成功したら、ビルドを壊した人に (冗談めかして) 行ってみてください。
全員がコードベースの所有権を持ち、責任を負う必要があります。
正直なところ、それは自分の技術に誇りを持つことでもあります。最終的に、ビルドが壊れていても人々が気にせず、それを整理するように求められた後も気にしない場合は、他の仕事をしたほうがよいように思えます.
修正を延期するほど、修正に時間がかかります。
すぐに直せば、壊れてしまう原因はみんな頭の中で新鮮なはずです。重大な変更はまた、積み重なって、後で修正するのがはるかに頭痛の種になる可能性があります。
それを修正することが重要です。先延ばしにすればするほど、後で見つけるものが増えます。クリーン ビルドで開始しない場合、変更によってビルドが壊れているかどうかを確認するにはどうすればよいでしょうか?
私たちの標準は、コミット後に中立的な統合ボックスですべての単体テストと機能テストを「グリーン」で実行することです。もちろん、テスト駆動開発は私たちの状況には適していますが、あなたの状況には合わないかもしれません。プロジェクトをビルドすることさえできない場合は、以前のコミットに予期せぬ事態が潜んでいる可能性があります。
ビルドにかかる時間が大きすぎて修正できない場合は、小さなプロジェクトに分割したり、継続的インテグレーションを行うなどの手法が役立つ場合があります。
私の友人は、運命のズッキーニを持っていた彼のチームについて教えてくれました。 ナイトリー ビルドを破った人は、ZoD を机の上に表示する必要がありました。この野菜はかなり腐敗が進んだ状態にあり、壊れたビルドは許されるものではないというメッセージをはっきりと送信していました.
チームがナイトリーの構築を維持するのに十分な動機を持っていない場合、これはマネージャーによって強制/奨励されるべきものです.