私は、CI の利点に関するデータについて、しばらくの間研究を続けてきました。しかし、確かなデータは見つかりませんでした。このトピックの例について議論しているスレッドはほとんどありません:
しかし、それらのほとんどは抽象的な例を扱っています:「壊れた/互換性のないコードの早期警告」
このようなものは、私たちが測定することはできません。ビルド プロセスに継続的インテグレーションが追加された場合の「バグ数」、「ビルド時間」、「欠陥解決時間」などの測定可能なデータを見た人はいますか
私は、CI の利点に関するデータについて、しばらくの間研究を続けてきました。しかし、確かなデータは見つかりませんでした。このトピックの例について議論しているスレッドはほとんどありません:
しかし、それらのほとんどは抽象的な例を扱っています:「壊れた/互換性のないコードの早期警告」
このようなものは、私たちが測定することはできません。ビルド プロセスに継続的インテグレーションが追加された場合の「バグ数」、「ビルド時間」、「欠陥解決時間」などの測定可能なデータを見た人はいますか
collab.net のこのホワイト ペーパーは非常に役に立ちました。
http://www.collab.net/content/building-value-continuous-integration
続行するのに十分なデータが得られることを願っています。
乾杯!
スティーブ
メトリックは、定量的または定性的です。
ビルド時間などの定量的な指標を測定する方が簡単です。そして、ビルド時間を測定することには実際に利点があり、私はそれを見てきました。たとえば、生産的なコーディングに不可欠な「フィードバック時間」に影響を与えるものは、ビルド時間が妥当な制限を超えていることを発見する可能性があるため、「制限を超えたトリガー」に基づいて行動する可能性があります。たとえば、この特定のケースでは、ソリューションを複数のコンポーネントに分割するか、「段階的な」統合などを行うことを検討してください。
プロジェクトの可視性やチームの満足度など、定性的な指標を測定することはより困難です。たとえば、CI は物事 (ビルド/テスト/リリース/デプロイ/その他のプロセス/ステータス) を誰にでも見えるようにし、より早く見えるようにします。したがって、CI ROI は可視性の向上による ROI に依存します。また、可視性の結果を測定することは困難ですが、可能であり、定性的な指標です。定性的な指標を把握する 1 つの方法は、定期的な調査を行うことです。適切な調査を作成することは別の科学ですが、たとえば、この場合、次のステートメントを 1 (正しくない) から 5 (完全に当てはまる) で評価するように人々に依頼することができます。 ."
それが役に立てば幸い。