どの時点で継続的インテグレーションサーバーが興味深いのでしょうか。

私はJenkinsのようなCIサーバーについて少し読んでいますが、疑問に思っています。

確かに、クラスが5つと単体テストが10つしかない小さなプロジェクトの場合は、実際には必要ありません。

ここでは約1500のユニットテストがあり、（古いCore 2 Duoワークステーションで）約90秒で合格します（実際に「ユニット」をテストしているため、非常に高速であるため）。私たちのルールは、テストが失敗するとコードをコミットできないということです。

したがって、各開発者はリグレッションを防ぐためにすべてのテストを開始します。

明らかに、すべての開発者が常にすべてのテストを起動するため、ある開発者が別の変更を（ある場合）プルするとすぐに、変更の競合によるエラーをキャッチします。

それでもまだはっきりしていません。JenkinsのようなCIサーバーをセットアップする必要がありますか？それは何をもたらすでしょうか？

速度向上に役立つだけですか？（私たちのケースでは問題ではありません）

古いビルドを再作成できるので便利ですか？（ただし、Mercurialでこれを行うには、古いリビジョンをチェックアウトします）

基本的に私はそれが役立つことを理解していますが、正確な理由はわかりません。

上記で提起したポイントを考慮した説明は大歓迎です。

速度向上に役立つだけですか？（私たちのケースでは問題ではありません）

プロセスの循環に費やした時間は、開発の流れに入るのに費やした時間です。

また、CDに直接書き込んだり、Webにアップロードしたりできる、完全にパッケージ化された出荷可能なビットを理想的に構築しているため、マイルストーンの時間を節約できます。

古いビルドを再作成できるので便利ですか？（ただし、Mercurialでこれを行うには、古いリビジョンをチェックアウトします）

いいえ、ビルドを再作成しません。作成したビルドを使用し、保持設定によって破棄されるまで保持します。

一部のDevのボックスではなく、ビルドサーバーでビルドします。

ここでは約1500のユニットテストがあり、（古いCore 2 Duoワークステーションで）約90秒で合格します（実際に「ユニット」をテストしているため、非常に高速であるため）。私たちのルールは、テストが失敗するとコードをコミットできないということです。

さらに、コードに対して自動統合テストまたはエンドツーエンドテストを実行して、単体テストで検出できない問題を検出できるようにしたくないですか。

それらを開発ボックスで実行したくないのは、その環境をセットアップして維持するのが面倒だからです。統合テストは、実行が非常に遅くなる傾向もあります。

どの時点で役立ちますか？

他の投資と同じです。

一度使用すると、後ろに出たり、壊れたりするだけです。複数のプロジェクトで使用すると、おそらく先に出てくるでしょう。

また、作成するアプリケーションの種類にも依存します。

JavaアプリケーションサーバーまたはIISにデプロイする必要があるWebアプリケーションを作成する場合、CIは非常に簡単になります。プロジェクトの一部としてデータベースがある場合も同じです。展開を手動で実行するのは面倒であり、QAチーム（ある場合）はある時点で毎日同じくらい頻繁にそれを必要とします。

また、ニーズと問題がJoel Spolskyの12 Steps to Better Codeとどのように一致するかを確認することもできます。特に2、3、10（すべて興味深いもので重要ですが）。

どの時点で役立ちますか？

• ビルド+テストサイクルは数分かかります。5分のテストを実行すると、特に小さな変更の場合、すべてのテストを自分で実行する必要がなくなります。
• 複数のバリアントの作成を開始します。カスタマイズが異なる2人の顧客がいる場合は、各バリアントに対してテストを実行する必要があります。これにより、作業量が非常に速く増加し始めます。開発者のマシンで1つのバリアントのテストスイートを実行し、それをCIに任せて残りを実行します。
• 重要なテスト環境のセットアップが必要な自動統合テストを作成します。開発の変更により、開発者の環境がさまざまな方法で変更される可能性があるため、1つの正規のテスト環境に対してテストしたい場合。CIは正規環境に最も適した場所です。
• テスターは、CIから最新のビルドをプルすることができます。したがって、開発ツールを所有、学習、使用する必要も、開発者がビルドを手動で送信する必要もありません。
• リリースの準備をしているとき：
  • テストがより重要になるので、テスト用にビルドを1か所にまとめておくとさらに便利です。
  • すべてのビルドが同じビルド環境でビルドされていることが確実であるため、開発者のインストール間の微妙な違いによって引き起こされる可能性のある問題を回避できます。
  • バージョン管理システムでチェックされたものを正確に構築していることは確かです。開発中に誰かが何かをチェックインするのを忘れた場合、次の開発者が失敗するため、すぐに見つけることができます。しかし、そのようなビルドがQAまたは本番環境に移行し、バグを報告した場合、追跡が非常に困難になります。

おそらくまだCIは必要ないかもしれませんが、テスト段階に入ると、CIは役立つと思います。Jenkinsは数時間でセットアップされ、テストを簡素化し、愚かな間違い（特に、本番環境への迅速な修正を急ぐときに発生する）を回避するのに役立ちます。

私にとって、チームに複数のメンバーがいる場合、CIは興味深いものになります。

CIを「私のためにテストを実行している別のPC」と考えるのをやめる必要があります。定義および自動化されたビルドプロセスとリリース管理に関するCI 。

CIは、ソフトウェアリリースを作成する単一の信頼できるエンティティです。CIに基づいて構築されない場合は、発生しませんでした。

CIを使用すると、すべてを自動化するための制限があり、手動で行った調整、ハック、ショートカットをすべて表示し、CIで機能しないため、最初は避ける必要があります。

回避する問題：

• 誰がリリースを作成する責任がありますか
• この人は24時間年中無休ですか
• しかし、それは私の機械症候群に基づいています
• 私たちがリリースしたバージョンについてのあいまいさをすべて取り除きます

利点（すべてを述べるには多すぎる）：

• 自動バージョン番号付け
• 課題追跡の統合
• 自動メトリック生成
• 静的コード分析
• 自動展開
• 多段階セットアップ

継続的インテグレーション（CI）に関する根本的な問題が1つあります。これは、質問に完全に反映されています。CIサーバーソフトウェアのセットアップは簡単ではなく、CIを介してプロジェクトを稼働させることも簡単ではないため、CIの実践は実装および防御が困難です。サーバ。これにより、CIを採用するメリットがどこにあるのかを実際に確認することが難しくなります。

まず第一に、CIは洞察と品質についてです。Good CIはプロジェクトに近づき、品質指標、ドキュメント、コーディング標準への準拠などに関する適切なフィードバックを提供します。これにより、これらすべてを簡単に視覚化し、一目で認識して簡単に確認できるツールが提供されます。一連の変更を、これらすべてのプロジェクトメトリックの特定のスナップショットに関連付けます。

単体テストを実行するだけではありません。どういたしまして！これは私に品質をもたらします。CIはエラーを受け入れ、それを回避したり、破棄したりしません。それが行うことは、後からではなく、早期にエラーを発生させるツールを提供することです。したがって、以前にテストしたコードをCIサーバーに実際にコミットすることはありません。クリーンで壊れていないコードをコミットするよう努力する必要がありますが、実際にはCIサーバーを使用して、コードを通じて統合ビルダーを自動的に実行し、すべてが正しく行われているかどうかを評価させます。あれば、きちんと！問題がなければ、問題ありません。CIの適切な慣行では、次の優先事項は、破損したものを修正することです。これは、優れたCIサーバーでは簡単に指摘できます。

チームのサイズが大きくなると、当然、全員のコードの統合は難しくなります。統合されたすべてのパーツをテストし、チームのメンバーからその負担を取り除くことは、集中型CIサーバーのタスクである必要があります。したがって、すべての人に早期に（そして可能な限り明確に）コミットしてから、ビルドのステータスを監視する必要があります（通常、通知が発生します）。繰り返しになりますが、開発者のコ​​ミットによって何かが壊れた場合、すぐにそれを修正し、それらの自動ビルドをすぐにOKステータスに戻すのが彼の責任になります。

つまり、私の意見では、すべてのプロジェクトは継続的に統合されていることからメリットを得ています。問題は、これまで、私が知っているすべてのCIサーバーの非常に複雑な複雑さのために、人々は実際に、より小規模な/より単純なプロジェクトでのCIプラクティスを回避しました。なぜなら、人々は、醜くて複雑すぎて配信不足の肥大化したソフトウェアを構成するのに何日も費やすよりも、やるべきことをしているからです。

私はこれとまったく同じ問題を抱えていました。それが、約1年前からの空き時間でCintientを開発した理由です。私の前提は、インストール、構成、および使用を簡単にして、他のすべての人がほとんど失敗または配信不足である品質メトリックを提供できるようにすることでした。したがって、この長い答えの後に、プロジェクトのGitHubリンク（無料でオープンソースのナッチ）を指摘するという恥知らずなプラグインが出てきます。また、明らかにいくつかの素晴らしいスクリーンショットがあります。:-) https://github.com/matamouros/cintient

お役に立てば幸いです。

（注：より適切な回答を作成するためにより多くの時間をかけるべきだったという事実についての、Bryan Oakleyのコメントの後に編集されました。私も彼が正しかったと思います。）