continuous-integration - デイリービルド vs. 欠陥ゼロ

Question

日々のビルドをどのように行い、欠陥ゼロの環境を目指していますか? 新しいコードのすべてのバグを殺すまで家に帰れないということですか? それとも、完全にテストするまでコードをチェックインしないということですか?

私は初めて少数のプログラマーと作業しているので (自分で作業したり、他の 1 人のコーダーと作業したりするのではなく)、このような決定に初めて取り組んでいます。ソフトウェア開発プロセスを採用する必要がありますか?

score 15 · Accepted Answer

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

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

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

ビルドを成功させることから始めて、可能な限りその状態を維持してください。チーム環境では不可欠です。ビルドが壊れることを覚えておいてください。時々壊れることが予想されます。これは、誤って悪いものをチェックインしたことを示しており、ビルドを再び緑色にするために行っていることを停止します。ビルドが壊れたことがないビルドサーバーは警告サインです。

私も chadmyers の答えに同意します。この種の作業を自動化するツールの最も優れた点は、それについて考えたり、実行することを覚えたりする必要がなくなることです。または、チャドが言ったように、あなたはそれをやめません. CI ツールを推奨することをお勧めしますが、こちらをご覧ください:自動ビルド / 自動展開にどのツールを使用していますか? なんで？

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

自動ビルドに適したツールを使用する

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

積極的な開発のためのブランチとトランク

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

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

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

score 6 · Accepted Answer

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

では、私の会社はどのようにして日々のビルドを行い、欠陥ゼロを目指しているのでしょうか? コードをチェックインする前に、テストスイートを実行します。私たちに固有の問題は、テストスイートの完全な実行に 72 時間以上かかることです。そのため、コードをチェックインする前に、限られた一連の単体テストを実行します。毎晩のビルドでは、実行に約 8 時間かかる一連のテストを実行します。その後、週末に完全なテストスイートを実行します。各段階でより多くの問題が検出されますが、5 分間の開発者テストで 90% 以上が検出され、夜間テストではおそらく 98% 以上が検出されます。これにより、問題が顧客に伝わり、修正に多額の費用がかかる前に、かなり早い段階で問題を警告することができます。

score 4 · Accepted Answer

これは、はるかに小さなコミットを行うことを意味します。作業リビジョンを頻繁にコミットすればするほど、自分の作業コピーが壊れることは少なくなります。反復開発はあなたから始まります。

score 3 · Accepted Answer

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

重要: 欠陥を少なくするには、迅速なフィードバックが必要です。ビルドに何分も、場合によっては 1 時間以上かかる場合、最終的にはビルドが嫌いになり、ビルドを回避することを学び、実行をできるだけ少なくするようになります。ビルドの価値は急速に低下し、無価値になり、欠陥数は減少します。急上昇し始めます。

ビルドを高速に実行するために、事前に時間を投資してください。遅いものがある場合は、なぜ遅いのかを調べ、それを取り除きます。それができない場合は、少なくともカスケードビルドをセットアップして、ビルドの残りの部分が高速になり (2 ～ 5 分未満と考えてください)、長時間実行されるものが直後に続き、必要なだけ時間がかかるようにします (ただし、試してみてください)。 10mのトップの下に保つために）。

言い尽くせませんが、変更に関する迅速なフィードバックサイクルは非常に重要です。

score 2 · Accepted Answer

秘訣は、できるだけ頻繁にチェックインすることです。いくつかのテストに合格しただけで、チェックインしてください! 1 つのバグを修正しました。チェックインしてください。可能な最小の増分を見つけて、チェックインしてみてください! これには、実際に関連性のあるチェックインコメントを書き込むことが実際に可能であり、説得力があるという追加の利点があるため、これは素晴らしいボーナスです。

もちろん、それには、夜間よりも頻繁に構築する CI 環境が必要です。可能な限り頻繁に構築することが実際に最適なオプションです。

ああ、覚えておいてください、それが決して壊れないなら、あなたはそれを間違っています. （つまり、あなたは過度に保守的で、時々少し壊れているだけで、うまくいけばそれを推進していることを示しています。）

score 1 · Accepted Answer

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

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

最後に、CruiseControlのようなツールは便利ですが、Jim Shoreが言ったように、継続的インテグレーションはツールではなく態度であることを理解してください。重要なのは、コードを機能させ続けるというグループの取り組みです。

score 1 · Accepted Answer

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

これについての私の考えは、毎日のビルドを特定の時間に自動化する必要があるということです。これより前にチェックインされていないコードはビルドされず、2 日間 (ビルド) 続けて誰かからのチェックインがない場合、これは警告サインであるため、ビルドシステムは彼らとテクニカルリードに通知する必要があります。

score 1 · Accepted Answer

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

ブランチがビルドを壊すことで、ある程度の不名誉が残るかもしれませんが、幹を壊すよりは問題はありません。

score 1 · Accepted Answer

欠陥ゼロ戦略について: コードに既知のバグがある場合は、家に帰ることができます。それは、新しい機能が実装される前に、欠陥を修正する必要があるということです。

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

score 0 · Accepted Answer

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

欠陥管理システムの要点は、まさにそれです-欠陥を管理できるようにするためです。欠陥が目を見張るようなものである場合は、確かにチェックインしたくないでしょうが、マイナーなケースやエッジケースの場合は、既知の欠陥を使用してチェックインするのが理にかなっている場合があります。それを再追跡します。

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

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

score 0 · Accepted Answer

CI引数については@feverentcoderを使用します。CIはあなたの友達です、彼にあなたを助けさせてください！

ブランチ/トランクポイントについては、全員が常にトランクで作業する必要があります。ブランチはスパイクとPOC用であり、すべてのリリースにタグを付けます。

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

continuous-integration - デイリー ビルド vs. 欠陥ゼロ

11 に答える 11

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

自動ビルドに適したツールを使用する

積極的な開発のためのブランチとトランク

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

Related

Reference

continuous-integration - デイリービルド vs. 欠陥ゼロ