現在、私たちの組織は継続的インテグレーションを実践していません。
CI サーバーを稼働させるためには、投資収益率を示す文書を作成する必要があります。
バグを早期に見つけて修正することによるコスト削減以外に、このドキュメントに記載できるその他の利点/節約に興味があります。
質問する
3542 次
9 に答える
15
私が CI を気に入っている一番の理由は、開発者が壊れたコードをチェックインするのを防ぐのに役立つためです。休暇に出発する直前に、いくつかのデータベース スキーマの変更を含む重要なチェックインを行ったとします。確かに、すべてが私の開発ボックスで正常に動作しますが、些細なことかもしれないしそうでないかもしれないデータベーススキーマ変更スクリプトをチェックインするのを忘れています。さて、データベース内の新しい/変更されたフィールドを参照する複雑な変更がありますが、翌日オフィスにいる誰もその新しいスキーマを実際に持っていません。チェックインするのを忘れただけです。
はい、私はデータベースの変更で特に厄介な例を使用しましたが、実際には何でもかまいません。おそらく、すべての開発者が実際のエンドユーザーにスパムを送信する原因となる電子メールコードを使用した部分的なチェックインですか? あなたはそれに名前を付けます...
したがって、私の意見では、これらの状況の 1 つを回避することで、そのような努力の ROI が非常に迅速に報われます。
于 2010-03-26T14:17:30.513 に答える
10
標準的なプログラム マネージャーと話している場合、単純な ROI という点で継続的インテグレーションを理解するのは少し難しいと感じるかもしれません。一定の投資額と引き換えに、どのような物理的な製品が得られるかはすぐにはわかりません。
私が学んだ方法は次のとおりです。「継続的インテグレーションは、プロジェクトからあらゆる種類のリスクを排除します。」
リスク管理は、お金がどのように使われるかを心配するよりもコードの記述に多くの時間を費やす、通常のソフトウェア エンジニアリング タイプの枠を超えたプログラム マネージャーにとって深刻な問題です。このような人々と効果的に仕事をするためには、彼らが理解できる言葉で私たちが知っている良いことを表現することを学ぶ必要があります.
これらのような会話で私が切り出すリスクのいくつかを次に示します。賢明なプログラム マネージャーのおかげで、最初のポイントの後で、私はすでに議論に勝っていることに注意してください。
- 統合のリスク: 継続的統合ベースのビルド システムでは、「長い週末に家に帰る前にファイルをチェックインするのを忘れた」などの統合の問題によって、開発チーム全体が金曜日の作業をすべて失う可能性ははるかに低くなります。 . このようなインシデントを 1 つ回避することで得られるプロジェクトの節約額 = チームの人数 (悪役がチェックインを忘れたためマイナス 1 人) * 1 日あたり 8 時間 * エンジニア 1 人あたりの時給。このあたりでは、プロジェクトに請求されない数千ドルに相当します。ROI 勝ち！
- リグレッションのリスク: ビルドのたびに実行される単体テスト/自動テスト スイートを使用すると、コードの変更によって正常に動作していたものが壊れるリスクを軽減できます。これははるかにあいまいで、確実性が低くなります。ただし、少なくとも、最も退屈で時間のかかる (つまり、費用のかかる) 人間によるテストの一部を自動化に置き換えるフレームワークを提供しています。
- テクノロジー リスク: 継続的インテグレーションにより、新しいテクノロジー コンポーネントを試す機会も得られます。たとえば、最近、Java 1.6 update 18 がリモート サイトへのデプロイ中にガベージ コレクション アルゴリズムでクラッシュすることがわかりました。継続的インテグレーションにより、アップデート 17 に戻すことで、アップデート 18 では機能しなかった場所で機能する可能性が高いという確信が持てました。この種のことは、現金価値の観点から表現するのははるかに難しいですが、リスクの議論を使用することはできます: プロジェクトの特定の失敗 = 悪い. グレースフル ダウングレード = はるかに優れています。
于 2010-03-26T15:21:48.497 に答える
5
CI は問題の発見を支援します。コード内の壊れたビルドまたは重大なバグを発見するのに現在かかる時間を測定します。その期間にそのコードを使用する各開発者の会社のコストを掛けます。これに年間の破損回数を掛けます。
あなたの番号があります。
于 2010-03-26T15:08:36.200 に答える
4
成功したすべてのビルドはリリース候補であるため、更新とバグ修正をより迅速に提供できます。
ビルド プロセスの一部でインストーラーが生成される場合、これにより展開サイクルも高速化されます。
于 2010-03-26T14:15:22.483 に答える
3
ウィキペディアから：
- 単体テストが失敗したり、バグが発生したりした場合、開発者はデバッグに時間を費やすことなく、コードベースをバグのない状態に戻すことができます。
- 開発者は、統合の問題を継続的に検出して修正します。これにより、リリース日の土壇場での混乱 (誰もがわずかに互換性のないバージョンをチェックインしようとするとき) を回避できます。
- 壊れた/互換性のないコードの早期警告
- 競合する変更の早期警告
- すべての変更の即時単体テスト
- テスト、デモ、またはリリースの目的で「現在の」ビルドを常に利用できる
- 開発者が記述しているコードの品質、機能、またはシステム全体への影響に関する開発者への即時フィードバック
- 頻繁なコード チェックインにより、開発者はモジュラーで複雑でないコードを作成するようになります
- 自動化されたテストと CI から生成された指標 (コード カバレッジ、コードの複雑さ、機能の完成度に関する指標など) は、機能的で高品質なコードの開発に開発者を集中させ、チーム内で勢いをつけるのに役立ちます。
- 最適なユーティリティに必要な、十分に開発されたテスト スイート
私たちは CI (1 日 2 回のビルド) を使用しており、テストとリリースのために作業コードを利用できるようにしておく時間を大幅に節約できます。
開発者の観点から見ると、CI は、電子メールで全世界 (開発者、プロジェクト マネージャーなど) に送信される自動ビルド結果に次のように表示されると、威圧的になる可能性があります 。 " そしてあなたは XYZ さんで、彼らはあなたが誰であるかを知っています :)!
于 2010-03-26T14:15:17.447 に答える
3
これが私の経験からの私の例です...
当社のシステムには複数のプラットフォームと構成があり、70 人を超えるエンジニアが同じコード ベースで作業しています。あまり使用されていない構成では約 60% のビルド成功率で、最も一般的に使用される構成では 85% のビルド成功率でした。コンパイル エラーやその他の障害に関するメールが毎日のように殺到していました。
大まかな計算を行ったところ、悪いビルドによってプログラマー 1 人あたり 1 日平均 1 時間が失われたと見積もられました。これは、プログラマーが最新のコードが安定しているかどうかわからないという理由で最新のコードへの同期を拒否する反復時間で発生するコストを考慮に入れていないため、さらに多くのコストがかかります。
Team City が管理するビルド サーバーのラックを展開した後、すべての構成で平均 98% の成功率が得られ、平均コンパイル エラーが数時間ではなく数分間システムに留まり、ほとんどのエンジニアが快適に最新のリビジョンを維持できるようになりました。コードの。
一般に、全体的な節約の控えめな見積もりは、CI を展開する前の 3 か月と比較して、プロジェクトの最後の 3 か月で約 6 人月であったと言えます。この議論により、リソースを確保してビルド サーバーを拡張し、エンジニアの時間を追加の自動テストに集中させることができました。
于 2010-03-26T17:08:15.950 に答える
1
私たちの最大の利点は、QA 用に毎晩ビルドを行うことです。私たちの古いシステムでは、各製品は、少なくとも週に 1 回、誰かが不正なコードをチェックインしたことを午前 2 時に発見していました。これにより、QA がテストするためのナイトリー ビルドが発生しませんでした。解決策は、リリース エンジニアリングに電子メールを送信することでした。彼らは問題を診断し、開発者に連絡します。QA が実際に作業する前に正午までかかることもありました。今では、優れたインストーラーを毎晩用意するだけでなく、サポートされているすべての構成の VM に毎晩実際にインストールしています。そのため、QA が開始されると、数分以内にテストを開始できます。古い方法を考えると、QA がインストーラーを取得し、すべての VM を起動してインストールし、テストを開始しました。QA 担当者 1 人あたり、構成ごとにテストするための QA 時間をおそらく 15 分節約できます。
于 2010-03-26T15:17:57.913 に答える
0
利用可能な無料の CI サーバーと、NAnt のような無料のビルド ツールがあります。開発ボックスに実装して、利点を発見できます。
ソース管理とバグ追跡システムを使用している場合、常に最初に (チェックインのたびに数分以内に) バグを報告することは非常に説得力があると思います。それに自分のバグ率の減少を加えれば、おそらく売上が上がるでしょう。
于 2010-03-26T15:44:06.270 に答える
0
ROI とは、実際には、顧客が望むものを提供する能力です。もちろん、これは非常に主観的なものですが、エンド カスタマーの関与を得て実装すると、顧客は得られるものを高く評価し始め、ユーザーの受け入れ時に問題が少なくなる傾向があります。
- それはコストを節約しますか？そうでないかもしれない、
- プロジェクトは UAT 中に失敗しますか? 絶対にいいえ、
- プロジェクトはその間に閉じられますか? - これが期待される結果をもたらさないことに顧客が気付いた場合の可能性が高い。
- プロジェクトに関するリアルタイムの実際のデータを取得しますか - はい
そのため、より早く失敗するのに役立ち、リスクを早期に軽減するのに役立ちます。
于 2014-04-16T11:10:57.927 に答える