デイリービルド vs.ゼロディフェクト

Question

毎日のビルドをどのように行い、欠陥のない環境を目指していますか?新しいコードのバグをすべて取り除くまでは家に帰れないということでしょうか?それとも、完全にテストが完了するまでコードをチェックインしないだけで、コードが事実上分岐した状態で長時間放置されるということなのでしょうか?

私は初めて数人のプログラマーと協力することになるので (自分で作業したり、他の 1 人のプログラマーと作業したりするのとは対照的に)、このような決定を下すのは初めてです。ソフトウェア開発プロセスを採用すべきでしょうか?

Answer 1

はい、ソフトウェア開発プロセスを採用してください。そこにはさまざまなものがありますが、そのうちの2つ以上があなたのチームに適合すると確信しています。完全に一致しないものであっても、プロセスがまったくないよりもはるかに優れています。

では、私の会社はどのようにして、毎日のビルドを行い、欠陥ゼロに努めていますか？コードをチェックインする前にテストスイートを実行します。私たちに特有の問題は、テストスイートのフル実行に72時間以上かかるため、コードをチェックインする前に限定されたユニットテストを実行することです。ナイトリービルドでは、実行に約8時間かかる一連のテストを実行します。その後、週末に完全なテストスイートを実行します。各段階ではより多くの問題が検出されますが、5分間の開発者テストでは90％以上、夜間テストではおそらく98％以上が検出されます。これにより、問題がお客様に届く前に、問題をかなり早期に警告し、修正に多くの費用がかかります。

Answer 2

単純：コードを決してチェックインしないでください (既知) その中にバグがある。これは、1 日に 1 回チェックインするという意味ではありません。意味のある変更が実装されたらチェックインして、他の開発者がそれにアクセスできるようにします。

私たちは常にローカルで統合し、コードに対してテストを実行し、すべてが合格したらチェックインします。仕事中は1日に20～30回くらいチェックインします。ビルド サーバーは変更を取得し、システムに対してビルドを実行します。継続的インテグレーション (CI) は良いことです。:D

継続的インテグレーション - ビルドを自動化する

まずは正常に構築することから始めて、できるだけその状態を維持してください。それはチーム環境では不可欠です。ビルドは壊れる可能性があることに注意してください。時々壊れることが予想されます。これは、何か悪いものを誤ってチェックインしてしまったという兆候であり、ビルドを再びグリーンにするために行っている作業を中止します。壊れたビルドがまったくないビルド サーバーは危険信号です。

私もチャドマイヤーズの答えに同意します。何を決定するにしても、それは自動的かつ自動化される必要があります。この種の作業を自動化ツールで行うことの最も優れた点は、それについて考えたり、実行することを覚えたりする必要がなくなることです。あるいは、チャドが言ったように、それをやめないでください。CI ツールに関する推奨事項を作成することをお勧めしますが、ここを参照してください。 自動ビルド/自動デプロイメントにはどのようなツールを使用していますか?なぜ？

CI を取得したら、壊れたビルド トークンを導入してユーモア (および恥) を注入できれば、より高い品質を得ることができます。 http://ferventcoder.com/archive/2008/08/20/continuous-integration-enhancement--the-broken-build-token.aspx

自動ビルドには優れたツールを使用する

.NET 環境のほとんどの人は、NAnt または MSBuild スクリプトを使用して、後で CI サーバーに接続できる自動ビルドを作成します。始めたばかりの場合、私の提案は次のとおりです。 アッパーカット, これは、NAnt を使用する非常に使いやすいビルド フレームワークです。より詳しい説明を含む 2 番目のリンクは次のとおりです。 アッパーカット.

アクティブな開発のためのブランチとトランク

リリース専用にトランクを開いたままにしない限り、ブランチする必要はありません (つまり、他の全員があなたと同じブランチで作業していることになります)。ただし、トランクとアクティブな開発ブランチの両方に CI を配置することになります。

ソフトウェア開発プロセス

ソフトウェア開発プロセスに関する質問にも、答えははっきりとイエスです。ただし、抜本的な変更が必要でない限り、何も急ぐ必要はありません。移行したいプロセスを選択し、ゆっくりとプロセスの導入を開始します。そして評価、評価、評価。特定のプロセスがグループで機能していない場合は、何か間違ったことをしているのか、それとも単にそれを排除する必要があるのか​​を判断します。そして、そうしてください。最終的にどのようなプロセスが実行されるにせよ、それが機能しなければ機能しません。

Answer 3

これは、はるかに小さなコミットを行うことを意味します。作業リビジョンをコミットする頻度が高いほど、自分の作業コピーが破損する可能性は低くなります。反復開発はあなたから始まります。

Answer 4

早期に統合し、頻繁に統合し、迅速に統合します。 「毎日のビルド」ではなく、誰かがコミットするたびにビルドし、頻繁に（少なくとも1日に1回、できれば2回以上）コミットします。

重要：低欠陥には高速フィードバックが必要です。ビルドに数分または1時間以上かかる場合、最終的にビルドを嫌うようになり、ビルドを回避し、できるだけ実行しないようになります。価値がなくなるほど急速に価値が低下し、欠陥カウントが増加します。急上昇を始めます。

ビルドを高速に実行するための時間を事前に投入してください。遅いものがある場合は、遅い理由を見つけ、それを排除します。できない場合は、少なくともカスケードビルドをセットアップして、残りのビルドが高速になるようにし（<！> lt; 2〜5分と考えてください）、実行時間の長いものがすぐに続き、それが続く限り望んでいます（ただし、10mの高さを超えないようにしてください）。

十分に言えない：変更に関する迅速なフィードバックサイクルは非常に重要です！

Answer 5

トリックはできる限り頻繁にチェックインすることで、いくつかのテストに合格しただけで、チェックインできます！単一のバグを修正し、チェックインしてください！ 可能な限り小さな増分を見つけて、チェックインしてみてください！これには、実際に関連性のあるチェックインコメントを書くことを可能にし、納得させるという利点があります。

もちろん、夜間よりも頻繁にビルドするCI環境を用意する必要があります。可能な限り頻繁に最適なオプションを選択してください。

ああ、覚えておいてください、それが壊れないなら、あなたはそれを間違っているのです。 （つまり、あなたは過度に保守的であり、現在は少し壊れていますが、それをプッシュしていることを願っています）

Answer 6

欠陥がすべてなくなるまで家に帰らないと、家に帰ることはできません。

これに関する私の考えは、毎日のビルドは特定の時間に自動化されるべきだということです。これより前にチェックインされなかったコードはビルドされず、誰かからのチェックインが2日間連続でなかった場合（ビルド）、これは警告サインであるため、ビルドシステムはそれらと技術リーダーに通知する必要があります。

Answer 7

より実用的なアプローチの1つは、すべての開発でトランクとブランチに欠陥をゼロにし、トランクとブランチの両方で毎日ビルドすることですが、欠陥なしはdevブランチには適用されません。

ブランチがビルドを壊すことによるスティグマの一定のレベルがまだあるかもしれませんが、トランクを壊すよりも問題は少ないです。

Answer 8

答えを見てみると、誰もテスト駆動開発について言及していないことに驚いています。目標が欠陥ゼロである場合、それが開始するのに最適な場所です。

その後、ペアプログラミングを強くお勧めします。

CruiseControlなどのツールが有用であることを最後に理解しますが、ジムショアが言ったように、継続的な統合は、ツールではなく態度です。重要なのは、コードを機能させ続けるためのグループのコミットメントです。

Answer 9

zero-defect-strategyについて：コードに既知のバグがある場合は、家に帰ることができます。新しい機能を実装する前に、欠陥を修正する必要があります。

チーム全体に適用することはできませんが、開発者にバグが割り当てられている場合、そのバグはこの開発者が作成する必要がある新機能よりも優先されます。

Answer 10

構築しているものによっては、欠陥が許可されないアプローチを採用することが適切でない場合があります。私の個人的な意見では、それはめったにありません。

欠陥管理システムのポイントはまさにそれです-欠陥を管理できるようにすることです。欠陥が見事なものである場合、確かに、あなたはおそらくそれをチェックインしたくないでしょうが、それがマイナーなものまたはエッジケースである場合、既知の欠陥でそれをチェックインするのは理にかなっているかもしれません再追跡します。

欠陥の存在を許可すると、より重要なことに集中できます。たとえば、リリースに時間が限られている場合は、すべてを修正したり、すべての機能を使用したりする時間がない場合があります。エッジケースのマイナーなバグを10個修正するか、付加価値機能を作成するかのどちらかを選択する場合、実用的な選択は既知のバグとともに出荷することです。

欠陥ゼロは悪い考えだと言っているわけではありません-実際、各リリースサイクルの終わりまでにこれに努めています-しかし、ソフトウェア開発における多くのことと同様に、プラグマティズムは通常、純粋主義よりも現実世界でうまく機能します。

Answer 11

CI引数に@feverentcoderを使用します。 CIはあなたの友達です。彼に助けてあげましょう！

ブランチ/トランクポイントについては、誰もが常にトランクで作業する必要があり、ブランチ esはスパイクとPOC、タグすべてリリース

プロセスに関しては、通常、自分に関連するプラクティスを見つけて、それらの周りにマイクロプロセスを構築することが有益です。また、生産性が向上すると思われるプラクティス/プロセスのみを使用してください。最後に、勇気を出してください。1〜2週間練習してみて、それが自分に合っているかどうかを確認してください。そうでない場合は、捨ててください。電球を作るではないもう1つの方法を学びました！