継続的インテグレーションの前に何人の開発者が私たちにとって効果的ですか？

継続的な統合に関連するオーバーヘッドがあります。たとえば、セットアップ、再トレーニング、認識アクティビティ、データの問題であることが判明した「バグ」を修正するための停止、懸念事項のプログラミングスタイルの強制などです。

継続的インテグレーションは、どの時点でそれ自体に費用がかかりますか？

編集：これらは私の発見でした

セットアップは、VSSまたはTFSから読み取り、Nantを備えたCruiseControl.Netでした。

失敗のいくつかの理由を以下に示しますが、これらはセットアップとは関係ありません。

調査コスト：赤信号の原因がコード、データ品質、またはインフラストラクチャの問題（ネットワークの問題、ソース管理からのタイムアウトの読み取り、サードパーティサーバーなど）の真の論理的不整合によるものかどうかの調査にかかった時間ダウンなど）

インフラストラクチャに対する政治的コスト：テスト実行の各メソッドに対して「インフラストラクチャ」チェックを実行することを検討しました。ビルドサーバーを交換する以外、タイムアウトの解決策はありませんでした。赤テープが邪魔になり、サーバーの交換はありませんでした。

単体テストの修正コスト：データ品質の問題が原因の赤信号は、誤って記述された単体テストの指標になる可能性があります。そのため、データに依存する単体テストは書き直され、不良データによる赤信号の可能性を減らしました。多くの場合、ユニットテストを正確に実行できるように、必要なデータがテスト環境に挿入されました。データをより堅牢にすると、このデータに依存している場合、テストはより堅牢になります。もちろん、これはうまくいきました！

カバレッジコスト、つまり、既存のコードの単体テストの記述：単体テストカバレッジの問題がありました。単体テストのないメソッドが何千もありました。そのため、それらを作成するにはかなりの工数が必要になります。これはビジネスケースを提供するには難しすぎるため、今後、新しいパブリックメソッドにはユニットテストを使用することにしました。単体テストを行わなかったものは、「潜在的に赤外線」と呼ばれました。ここで重要な点は、静的メソッドは、特定の静的メソッドがどのように失敗したかを一意に判断する方法の重要なポイントであったということです。

オーダーメイドのリリースのコスト：Nantスクリプトはこれまでのところのみです。たとえば、EPiServer、CMS、またはUI指向のデータベース展開用のCMS依存ビルドにはあまり役立ちません。

これらは、1時間ごとのテスト実行と夜間のQAビルドのためにビルドサーバーで発生した問題の種類です。ビルドマスターはリリース時にこれらのタスクを手動で実行できるため、特にワンマンバンドと小さなビルドでこれらが不要であることを楽しませます。したがって、シングルステップビルドは、私の経験ではCIの使用を正当化するものではありません。より複雑なマルチステップビルドについてはどうですか？これらは、特にNantスクリプトなしでは、構築するのが面倒です。したがって、作成したとしても、これらはもはや成功しませんでした。赤信号の問題を修正するコストは、利益を上回りました。最終的に、開発者は興味を失い、赤信号の妥当性を疑問視しました。

公平に試してみましたが、CIは高価であり、単に仕事を終わらせるのではなく、周辺で多くの作業をしていると思います。アラームシステムを導入および保守するよりも、大規模なプロジェクトを大量に作成しない経験豊富な開発者を採用する方が、費用対効果が高くなります。

これらの開発者が去っても、これは事実です。優れた開発者が辞めるかどうかは問題ではありません。彼が従うプロセスにより、要件仕様、設計仕様を記述し、コーディングガイドラインに準拠し、コードが読みやすくなるようにコメントすることが保証されます。これはすべて見直されます。これが発生していない場合、彼のチームリーダーは仕事をしていません。これは、マネージャーなどが引き受ける必要があります。

CIが機能するためには、単体テストを作成し、完全なカバレッジを維持し、大規模なシステムの機能するインフラストラクチャを確保するだけでは不十分です。

結論：リリース前にできるだけ多くのバグを修正することがビジネスの観点からも望ましいかどうか疑問に思うかもしれません。CIには、顧客がUATで特定できる少数のバグをキャプチャするための多くの作業が含まれます。または、保証期間が期限切れになった場合、クライアントサービス契約の一部として会社が修正の支払いを受けることができます。

CIエンジンのセットアップは、家で火災警報器をセットアップすることに似ています。

私の考えでは、利点は多くの開発者とは関係なく、大規模なコードベースと相関しています。CIエンジンは、自分がやりたくない退屈な作業をすべて積極的に実行し、毎回実行します。

長時間触れていないリモートモジュールを壊した場合、すぐに通知されます。コンパイルだけでなく、単体テストを設定している場合は機能的にも賢明です。

また、インストーラーのセットアップなど、退屈な作業をすべて CIエンジンに任せる場合は、手動で行う必要はありません。ソースをチェックインするだけで、完成した製品が標準の場所でビルドされるのを待つことができます。（編集：CIエンジンは、明確に定義された環境でも機能し、開発者固有の設定を回避し、再現性を確保します）

これも品質保証の一部です。

編集：上記を書いた後、私はJava用のMavenビルドツールの経験がありました。基本的に、これによりプロジェクト内で完全なCI構成を（pom.xmlを使用して）維持できるため、CIインストールの維持や別のCIエンジンへの移行が非常に簡単になります。

開発者の数ではなく、1からn（包括的）に到達するまでに必要なステップ数です。

1：コードをチェックアウトし
、
n：インストール可能\展開可能なパッケージを持つ

n <2の 場合、CIは必要ないかもしれませんが、CI が必要です

更新
あなたの調査結果を読んで、私はあなたが間違った方向から間違った理由でCIにアプローチしたと結論付けることができます。

チームが1人でも努力するだけの価値はあります。これは、クロスプラットフォームコードを開発している場合に特に当てはまり、変更が両方のプラットフォームで機能することを確認する必要があります。たとえば、MicrosoftのC ++コンパイラはGCCよりも受け入れやすいので、Windowsで開発するがLinuxもサポートする必要がある場合は、Linuxでビルドが中断したときにCIシステムに通知してもらうと非常に役立ちます。

一部のCIシステムはセットアップが非常に簡単であるため、オーバーヘッドはそれほど大きくありません。たとえば、ジェンキンスまたはハドソンを試してください。

あなたが言うように、それをセットアップして実行し続けるためのオーバーヘッドコストがあります。

しかし、損益分岐点がどこにあるかという問題は、チームに何人いるかではなく、プロジェクトの長さの関数です。

そうは言っても、将来のすべてのプロジェクトで使用できるセットアップコストの一部があるため、長期的にはオーバーヘッドコストはゼロに近づく可能性があります。

今週、ジェンキンスをセットアップして、現在取り組んでいる小さな.NETプロジェクトを構築します。コミットごとにビルドをトリガーするように、Gitソース管理と統合しました。ユニットテストをビルドに統合しました。FxCopおよびStyleCop違反の形式で静的分析を統合しました。

これで、チェックインするたびに、すべてのコードをチェックアウトし、ビルドし、すべてのアセンブリのバージョン番号を増やし、テストし、FxCopおよびStyleCop違反がないか分析し、ビルドをアーカイブして、結果をいくつかのグラフに記録します。私はテスト結果と違反の経時的な可視性を持っています。

それを最初から行うには1時間ほどかかります（まだ行ったことがない場合は1日かかるかもしれません）。すべてのツールが無料で利用できるため、費用はかかりません。

もしプロジェクトが構築された時に、私が高品質のインフラストラクチャを持っているなら、それで無料で成長します。新しい開発者がプロ​​ジェクトに参加した場合、または参加したときに、無料で彼らの仕事とプロジェクトへの影響を完全に可視化できます。

だから、CIが価値がないとわかる唯一のシナリオは、1日ほどかかり、再訪しないプロジェクト、または既存の/無料のツールがなく、それらを取得するコストのない言語のプロジェクトの場合です仕事に不釣り合いです。

各変更後にプロジェクトのすべての側面を検証できる場合、CIは必要ありません。

他のすべての場合、それは純利益です。

オーバーヘッドは最小限です。一人の男のプロジェクトにとっては便利だと思います。2つに達すると、それは非常に貴重です。

ワンマンプロジェクトの場合、「ワンステップビルド/検証」がある場合は継続的な統合で問題ないかもしれませんが、そのような場合はCIをセットアップするためのほとんどのハードワークを行ったため、正式なシステム（CC、Hudson、TeamCityなど）。

CIがいつ自己負担するのかという質問は、新しいプロジェクトで答えるのが難しいものです。

既存のプロジェクトでは、見やすくなっています。サプライチェーンの開発部分で重大なバグを見つけた場合、問題は可能な限り早い時点で存在することがわかります。修正にかかる費用は今では最低です。その問題が開発以上の環境に存在する場合、コストが高くなります。

現在、経営陣はバグを伴ってリリースすることを決定するかもしれませんが、それはビジネス上のリスクです。少なくとも今では、毎晩の料金で請求された場合に非常に高価になる深夜の電話/パニックではなく、そのリスク評価によって軽減できます。

コストの観点から考慮すべきもう1つのこと。QA部門はどのようなものですか？手動テストですか？CIに移行すると、これらのスクリプトを開発ボックスに対して自動化することで、全体的なQAコストを削減できる場合があります。CIフェーズに参加させることで、プロジェクトをサポートするQAスタッフの数を減らすことができる場合があります。

CIには常に価値があります。CIを使用すると、他の方法よりも速い速度で作業できます。あなたが持っている問題は、単体テストを中心に展開しているようです。ユニットテストは非常に高価であることに同意しますが、（多くの点で）ユニットテストは私たちが持っている最も最悪の選択肢だと思います。個人的に、そして私が取り組んでいる種類のシステムについては、現実世界と（おそらく合成）病理学的ケースの組み合わせで動作するシステムレベルのテストを誓います。それは単体テストよりも安価であり、概念的な宇宙の到達困難なコーナー、ドナルド・ラムズフェルドの「未知の未知数」に入ります。

チームの規模に関係なく、常に使用してください。たとえば、スターバックスのラップトップからコーディングして、自宅のより機能的なシステムから続行するのは、あなただけの場合です。

オーバーヘッドはそれほど悪くありません。

1。はい、継続的インテグレーションの使用を開始するには十分です。

開発者の数の問題ではなく、

a。自動化を使用してどれだけの時間を節約し、どのくらいの頻度で。

• 統合後の構築、自動化されたテストの実行、セットアップの作成にかかる時間*チェックインの頻度=節約される時間の割合。

b。使用しているバージョン/ブランチ/製品の数。

• 1人の開発者が2つの異なるブランチで作業している場合、各ブランチではビルド、テスト、パッケージ化が必要になるため、節約される時間は2倍になります。