継続的インテグレーションの使用に対するいくつかの議論は何ですか？

Question

それを使用する理由はたくさんあると思います。ただし、マイナス面は何ですか？

（別のサーバーを購入する以外に）

デイリービルドの代わりにデイリービルドを使用する利点は何ですか？

Answer 1

（「継続的な統合」により、自動化 自動化ビルドプロセスと統合し、自動的にテストを実行し、< strong>自動的には各ピースの障害を検出します。

「継続的インテグレーション」も注目に値しますトランクまたはテストサーバーを意味します。 「すべての変更をライブでプッシュする」という意味ではありません。

間違って継続的な統合を行う方法はたくさんあります。）

---

継続的な統合テストを行わない理由は考えられません。 「継続的インテグレーション」を想定していると思います。テストが含まれます。コンパイルされたからといって、動作するわけではありません。

ビルドやテストに時間がかかる場合、継続的インテグレーションに費用がかかる可能性があります。その場合、コミットの前に変更に明らかに関連するテストを実行します（ Devel :: CoverX :: Covered は、どのテストがどのコードで実行されるかを発見するのに役立ちます）、 SVN :: Notify 、失敗した場合は開発者に警告します。 Smolder のようなものを使用して、テスト結果をアーカイブします。これにより、開発者はテストスイートの実行を見続けることなく迅速に作業しながら、ミスを早期に発見できます。

とはいえ、少しの作業で、ビルドとテストのプロセスをスピードアップできることがよくあります。多くの場合、低速テストは、各テストがあまりにも多くのシステムを指しているため、セットアップとティアダウンが多すぎて、小さなピースをテストするためにシステム全体をセットアップする必要があります。

デカップリングは、サブシステムを独立したプロジェクトに分割するのに役立ちます。スコープが小さいと、理解が容易になり、ビルドとテストが高速になります。各コミットは、プログラマーに迷惑をかけることなく、完全なビルドとテストを実行できます。その後、すべてのサブプロジェクトをまとめて収集し、統合テストを実行できます。

すべてのコミットでテストスイートを実行することの主な利点の1つは、コミット後であっても、ビルドの失敗を知っていることです。 「昨日やったことでビルドが壊れた」というよりも、もっと悪い「昨日やった4つのことでビルドがさまざまな方法で壊れてしまったので、解く必要があります」 「リビジョン1234ビルドが壊れた」ということです。問題を見つけるには、その1つのリビジョンのみを調べる必要があります。

デイリービルドを行う利点は、少なくとも毎日、完全でクリーンなビルドとテスト実行が行われていることを知っていることです。しかし、とにかくそれを行う必要があります。

Answer 2

マイナス面はないと思います。しかし、議論のために、ここに Eric Minickの記事があります。 UrbanCode on （＆quot;ビルドではなくテストに関するものです。＆quot;） Martin Fowlerの作品は、テストに十分な時間を与えられないと言っています。

＆quot; CIで本当に成功するために、ファウラーは、ビルドが自己テストである必要があり、これらのテストにはユニットテストとエンドツーエンドテストの両方が含まれていると断言します。同時に、ビルドはすべてのコミットで実行されるため、非常に高速（理想的には10分未満）である必要があります。エンドツーエンドのテストが多数ある場合、ビルド時にプロセス全体を10分未満に保ちながら実行するのは非現実的です。

コミットごとにビルドの需要を追加すると、要件はありそうもないと感じ始めます。オプションは、フィードバックが遅くなるか、一部のテストが削除されます。＆quot;

Answer 3

James Shoreには、CruiseControlなどのCIツールを使用することで継続的インテグレーションを行っていると考えることの危険性に関する一連のブログエントリがありました。

• CruiseControlが嫌いな理由
• 継続的な統合はツールではなく態度です
• 1日1ドルでの継続的な統合

CIサーバーを設定する際の危険の1つは、目標の移動です。 「高品質のソフトウェアを確保する」とは対照的です。そのため、テストの実行にかかる時間は気にしなくなります。その後、チェックインする前にすべてを実行するには時間がかかりすぎます。その後、ビルドが壊れ続けます。その後、ビルドは常に壊れます。人々はビルドをパスするためにテストをコメントアウトします。また、ソフトウェアの品質は低下しますが、ビルドは成功しています...

Answer 4

継続的インテグレーションがあまり意味をなさないのを見てきた2つのケースがあります。私はCIの大擁護者であり、可能な場合はそれを使用するように心がけてください。

最初のものは、ROIが意味をなさない場合です。現在、いくつかの小さな内部アプリを開発しています。通常、アプリケーションは非常に簡単で、開発のライフサイクル全体は約1週間または2週間です。 CIのすべてを適切に設定すると、おそらくそれが2倍になり、おそらくその投資が再び見られることはないでしょう。あなたは私がメンテナンスでそれを取り戻すと主張することができますが、これらのアプリは更新されると同時に破棄される可能性があります。あなたの仕事はおそらくソフトウェアを出荷することであり、100％のコードカバレッジに到達することではないことに注意してください。

私が言及した他のシナリオは、結果に対して何もしなければCIは意味がないということです。たとえば、ソフトウェアをQAに送信する必要があり、QAスタッフが数日ごとに新しいバージョンを実際にしか見ることができない場合、数時間ごとにビルドすることは意味がありません。他の開発者がコードメトリックを確認して改善しようとしない場合、それらを追跡しても意味がありません。これはCIが優れた手法ではないことのせいではなく、CIを受け入れようとするチームの不足です。それでも、このようなシナリオでCIシステムを実装することは意味がありません。

Answer 5

起動時、すべての設定に時間がかかります。

テスト、カバレッジ、静的コード検査、重複検索、ドキュメントのビルドおよびデプロイを追加する場合、正しく実行するには長い時間（週）かかります。その後、ビルドの維持が問題になる可能性があります。

たとえば、ソリューションにテストを追加する場合、ビルドにいくつかの基準に基づいてテストを自動的に検出させるか、ビルド設定を手動で更新する必要があります。自動検出を正しく行うのははるかに困難です。カバレッジについても同じです。ドキュメント生成と同じ...

Answer 6

継続的インテグレーションを行わない唯一の正当な理由は、インテグレーションテストで長い間欠陥を特定できず、毎回実行するのに時間がかかりすぎるまでプロジェクトを進めてしまった場合です。ビルドを行うとき。言い換えれば、十分な継続的インテグレーションを行って、もはや必要ないことを自分自身に証明したのです。