それを使用する正当な理由はたくさん考えられます。ただし、それの欠点は何ですか？
（別のサーバーを購入することは別として）
代わりにデイリー ビルドを使用する利点は何ですか?
6179 次
6 に答える
24
（「継続的インテグレーション」とは、自動ビルドプロセスとの自動統合を意味し、テストを自動的に実行し、各部分の障害を自動的に検出することを意味します。
また、「継続的インテグレーション」とは、トランクサーバーまたはテストサーバーを意味するだけであることにも注意してください。「すべての変更をライブでプッシュする」という意味ではありません。
継続的インテグレーションを間違って行う方法はたくさんあります。）
継続的インテグレーションテストを行わない理由は考えられません。「継続的インテグレーション」にはテストが含まれていると思います。コンパイルしたからといって、動作するわけではありません。
ビルドやテストに時間がかかる場合、継続的インテグレーションはコストがかかる可能性があります。その場合、コミット前に変更に明らかに関連するテストを実行し（Devel :: CoverX :: Coveredなどのカバレッジ分析ツールはどのテストがどのコードに適合するかを発見するのに役立ちます）、コミット後にSVNなどを使用して統合テストを実行します::通知し、失敗した場合は開発者に警告します。Smolderなどを使用してテスト結果をアーカイブします。これにより、開発者は、テストスイートの実行を監視することなく、ミスを早期に発見しながら、迅速に作業することができます。
とは言うものの、少しの作業で、ビルドとテストのプロセスをスピードアップできることがよくあります。多くの場合、遅いテストは、各テストがあまりにも多くのセットアップと分解を行わなければならず、あまりにも結合されているシステムを指しているため、小さなピースをテストするためだけにシステム全体をセットアップする必要があります。
デカップリングは、サブシステムを独立したプロジェクトに分割するのに役立つことがよくあります。スコープが小さいほど、理解が容易になり、ビルドとテストが高速になります。各コミットは、プログラマーに迷惑をかけることなく、完全なビルドとテストを実行できます。次に、すべてのサブプロジェクトをまとめて統合テストを行うことができます。
コミット後であっても、すべてのコミットでテストスイートを実行することの主な利点の1つは、ビルドが壊れた原因を正確に把握できることです。「昨日行ったことがビルドを壊した」、またはさらに悪いことに「昨日行った4つのことでビルドがさまざまな方法で壊れたため、解きほぐす必要がある」というよりも、「リビジョン1234がビルドを壊した」ということです。問題を見つけるには、その1つのリビジョンを調べるだけです。
デイリービルドを行うことの利点は、少なくとも、完全でクリーンなビルドとテスト実行が毎日行われていることを知っていることです。しかし、とにかくそれをする必要があります。
于 2008-10-18T08:01:30.973 に答える
12
マイナス面はないと思います。しかし、議論のために、UrbanCodeに関するEric Minickの記事があります （「ビルドではなくテストに関するものです。」）彼は、 Martin Fowlerの作業に基づくツールについて、テストに十分な時間がないことを批判しています。
「CIで真に成功するには、ビルドは自己テストであり、これらのテストにはユニットテストとエンドツーエンドテストの両方が含まれる必要があると主張します。同時に、ビルドは非常に高速である必要があります。理想的には10分未満です。 -コミットごとに実行する必要があるため。エンドツーエンドのテストが多数ある場合、プロセス全体を10分未満に保ちながらビルド時にテストを実行するのは非現実的です。
コミットごとにビルドの需要を追加すると、そして、要件はありそうもないと感じ始めます。オプションは、フィードバックを遅くするか、一部のテストを削除することです。」
于 2008-10-18T07:28:10.103 に答える
9
James Shore は、CruiseControl のような CI ツールを使用することは継続的インテグレーションを行うことを意味すると考えることの危険性について、すばらしい一連のブログ エントリを作成しました。
CI サーバーをセットアップする際の危険の 1 つは、「高品質のソフトウェアを確保すること」ではなく、「ビルドを成功させ続けること」が重要であると考えて、目標を変更することです。そのため、人々はテストの実行にかかる時間を気にしなくなります。次に、チェックインする前にすべてを実行するには時間がかかりすぎます。その後、ビルドは壊れ続けます。その後、ビルドは常に壊れています。そのため、人々はビルドを成功させるためにテストをコメントアウトします。ソフトウェアの品質は低下しますが、ビルドはパスしています...
于 2008-11-18T17:55:45.313 に答える
4
一般に、継続的インテグレーションが実際には意味をなさないのを目にした2つのケースがあります。私はCIの大きな支持者であり、できる限りそれを使用しようとしていることを忘れないでください。
1つ目は、ROIが意味をなさない場合です。私は現在、いくつかの小さな内部アプリを開発しています。通常、アプリケーションは非常に簡単で、開発のライフサイクル全体は約1〜2週間です。CIのすべてを適切に設定すると、おそらくその2倍になり、その投資が二度と戻ってくることはないでしょう。メンテナンスで元に戻すと主張することもできますが、これらのアプリは更新されると破棄される可能性があります。あなたの仕事はおそらくソフトウェアを出荷することであり、100％のコードカバレッジに到達することではないことを覚えておいてください。
私が言及した他のシナリオは、結果に対して何もしない場合、CIは意味をなさないというものです。たとえば、ソフトウェアをQAに送信する必要があり、QAスタッフが実際に新しいバージョンを確認できるのは数日おきである場合、数時間ごとにビルドを行うことは意味がありません。他の開発者がコードメトリックを調べて改善しようとしない場合、それらを追跡することは意味がありません。確かに、これはCIが優れた手法ではないという欠点ではなく、CIを積極的に採用するチームの欠如です。それにもかかわらず、そのようなシナリオでCIシステムを実装することは意味がありません。
于 2008-11-18T17:04:51.610 に答える
1
起動時は、すべての設定に時間がかかります。
テスト、カバレッジ、静的コード インスペクション、重複検索、ドキュメントのビルドとデプロイを追加すると、適切な状態になるまでに長い時間 (数週間) かかる可能性があります。その後、ビルドの維持が問題になる可能性があります。
たとえば、ソリューションにテストを追加する場合、ビルドにいくつかの基準に基づいてそれらを自動的に検出させるか、ビルド設定を手動で更新する必要があります。自動検出を正しく行うのははるかに困難です。カバレッジについても同じです。ドキュメント生成と同じ...
于 2008-10-19T22:27:16.560 に答える
-5
継続的インテグレーションを行わない唯一の正当な理由は、プロジェクトが機能して、統合テストで長い間欠陥が検出されず、実行するたびに実行に時間がかかりすぎる場合です。ビルド。言い換えれば、継続的インテグレーションを十分に行ったので、それが不要になったことを自分自身で証明できたということです。
于 2008-10-18T08:43:39.623 に答える