6

継続的なビルドと継続的な統合がソフトウェア製品の品質にとって有益であることは誰もが同意していると思います。欠陥は早期に発見されるため、できるだけ早く修正できます。数分かかる継続的なビルドの場合、通常、欠陥の原因を特定するのは簡単です。ただし、実行に時間がかかる夜間の統合テストの場合、これは困難な場合があります。最適な解決策を探している状況の詳細は次のとおりです。

  • 統合テストの実行には 1 時間以上かかります。したがって、それらは夜間に実行されます。毎日複数のチェックインが行われるため (約 15 人の開発者のチーム)、「犯人」 (存在する場合) を見つけるのが難しい場合があります。
  • 統合テスト環境は、他の環境 (Web サービスおよびデータベース) に依存しており、時々失敗する可能性があります。これにより、統合テストが失敗します。

では、これらの障害が早期に修正されるようにチームを編成するにはどうすればよいでしょうか? 私の意見では、欠陥を診断するために任命された人がいるはずです. これは、朝一番のタスクです。他の人の専門知識が必要な場合は、すぐに利用できるはずです。障害の原因 (コンポーネント、データベース、Web サービス) が特定されたら、所有者はその修正を開始する必要があります (または別のチームに通知する必要があります)。

欠陥を診断する人を任命する方法は？理想的には、誰かがボランティアをしてくれます（笑）。これはあまり頻繁には起こらないと思います。別の選択肢も聞いたことがあります。最初にオフィスに来た人は誰でも、毎晩のビルドの結果を確認する必要があります。チーム全体が同意すれば、これで問題ありません。しかし、これは遅れてきた人に報います。この役割はチーム内でローテーションするべきだと思います。「ビルドについてよく知らない」という言い訳は受け入れられません。障害の原因の診断はかなり簡単です。そうでない場合は、コードに診断ログをさらに追加すると、統合テストの失敗に対する可視性が向上します。

この分野での経験や上記のアプローチの改善のための提案はありますか?

4

7 に答える 7

6

Microsoft による壊れたナイトリー ビルドに関する有名なポリシーは、コミットがビルドを壊した人が、他の誰かが壊れるまでナイトリー ビルドを維持する責任を負うというものです。

それは理にかなっています。

  • 誰もが間違いを犯すため、必要なローテーションが発生します (あいまいなケースでは、最近使用されていない選択パターンが強化されます)。
  • 人々がより良いコードを書くことを奨励します
于 2009-12-22T15:16:18.087 に答える
3

私が通常行っていること (私は 8 人から 10 人のチームでこれを行いました)は、2 人に 1 人がビルドをチェックすることです。彼は朝一番に行います。私は考えます。

問題が発生した場合、彼は何をどのように見つけ出す責任があります。もちろん、必要に応じてチームの他のメンバーに助けを求めることもできます。

これは、アプリケーション全体について十分な知識を持っている必要があるチームのメンバーが少なくとも 1 人いることを意味しますが、それは悪いことではありません。アプリケーションが本番環境で使用され、障害が発生した日に問題を診断するのに役立ちます。

そして、 1人でそれを行う代わりに、2 人いる場合が好きです。このようにすると、誰かが休暇中であっても、問題を診断できる人が常にいる可能性が高くなります。


補足として、ビルド中にログに記録する有用な 情報が多ければ多いほど、何がうまくいかなかったのか、そしてその理由を簡単に見つけることができます。


チームの全員が毎朝ビルドをチェックできるようにしてみませんか?

  • まず第一に、すべての人がそうしたいとは限りません。
  • それに、10 人が毎日 30 分も費やしたくありません ^^
于 2009-12-22T15:07:32.463 に答える
2

あなたの場合、CMを担当する人なら誰でもいいと思います。それがマネージャーやテクニカル リーダーであり、あまりにも多くの責任を負っているのであれば、それを後輩の開発者に委ねてみませんか? キャリアの早い段階で、誰かが私にソース管理をもっと徹底的に理解するように強制してくれたらよかったのにと思います。それだけでなく、他の人のコードを見てエラーの原因を突き止めることは、真のスキル構築または知識学習の練習になります。他の人のコードを見ることで最大の利益が得られると彼らは言い、私はこれを固く信じています。

于 2009-12-22T15:11:11.640 に答える
1

経験者と未経験者のペア

開発者のペアが壊れたビルドを診断することを検討することをお勧めします。私はそれで幸運でした。特に、ビルド システムにほとんど慣れていないチーム メンバーと、非常によく知っているチーム メンバーをペアにする場合はなおさらです。これにより、チーム メンバーが義務から逃れようとして「ビルドについてよく知らない」と言う可能性が減り、バスの数が減り、共同所有権が増加します。


チームに、割り当てられたソリューションまたは自分で作成したソリューションのいずれかを選択させます

問題をチームに持ち込んで、解決策を提供するよう依頼することができます。彼らが実行可能な解決策を思いつかない場合は、毎週のスケジュールを作成し、1 日 1 組を割り当て、全員が参加できるようにすることを伝えます。

于 2010-01-11T18:22:34.943 に答える
1
  • 継続的インテグレーションを実践して、メガビルドを頻繁に行う必要がないようにする ** 1 台のマシンで実行するには遅すぎる場合は、マシン間でビルドを分散できます
  • ビルド ステータス モニターを使用して、何かをチェックインした人がビルドの失敗に責任を持つことができるようにします。
  • 午後のチェックイン締め切りがあります

また：

  • 午後5時以降誰もチェックインしない

また

  • ビルドが緑色になるまで仕事を続ける準備ができていない限り、午後 5 時以降にチェックインする人は誰もいません。

最初の形式を強制して従う方がはるかに簡単なので、それに従います。

私の元チームのメンバーは実際に電話を受け、ビルドを修正するために仕事に戻るように言われました...そして彼らはそうしました。

于 2010-01-14T12:15:59.400 に答える
0

毎朝、仕事を始める前にスタンドアップミーティングを行っています。チェックリストにあるものの1つは、ナイトリービルドのステータスです。私たちのビルドシステムは、実行後にステータスを報告する電子メールを吐き出すので、これは簡単に見つけることができます-たまたま、それは1人の人に送られますが、実際にはすべての人に送られるか、プロジェクトwikiに投稿する必要があります。

ビルドが壊れた場合、それを修正することが最優先のタスクになり、他のタスクと同じように処理されます。つまり、誰がそれに取り組むかをスタンドアップで決定し、次に彼らが行ってそうします。私たちはペアプログラミングを行い、通常これをペアタスクとして扱います。スタッフが不足している場合は、破損を調査するために1人を割り当て、少し後で修正するために誰かをペアにする場合があります。

タスクを割り当てるための正式なメカニズムはありません。私たちは小さなチーム（通常は6人）であり、コードの所有権は集合的であるため、自分たちの間で解決します。ある特定のペアのチェックインがビルドを壊したと思われる場合、通常、それを修正するのは彼らです。そうでない場合は、誰でもかまいません。それは通常、他のタスクの途中に誰がいないかを確認することによって決定されます。

于 2010-01-14T18:28:10.280 に答える
0

いくつかの方法のいずれかで物事を分割することをお勧めします。

  • 時間分割 - テストを 1 晩に 2 回実行できると仮定すると、2 つの異なる時点でコードに対してテストを実行しない理由はありません。つまり、午後 X 時までのすべてのチェックインと残りのチェックインです。問題は。

  • チームの分割 - コードを小さな部分に分割して、さまざまなマシンでテストを実行して、どのグループが掘り下げる必要があるかを絞り込むことができますか?

これは、テストを複数回実行し、そのような方法で分割できることを前提としているため、大まかな考えです。

于 2009-12-22T15:16:57.530 に答える