継続的インテグレーションを分析する

  • 4 分

継続的インテグレーションは、DevOps 分類の 8 つの機能の 1 つです。

継続的インテグレーションが必要な理由を探す

1999 年9 月 23 日、マーズ クライメイト オービターは、火星大気圏上空への一時的な降下に備えて太陽電池を充電しました。

この衛星は、正常に軌道に進入した後で、数年間にわたって火星の写真を地球に送ることになっていました。 しかし、残念なことに火星の大気中で燃え尽きました。

サード パーティによって提供された地上管制ソフトウェアのバグのために、値がヤード ポンド法のポンド秒で計算されたのです。 NASA が開発したソフトウェアでは、メートル法のニュートン秒の値が想定されていました。 これらの値が正しく変換されなかったため、衛星の位置のわずかな違いが積み重なって数百万マイルを超えることになりました。

その時点で NASA のコーディング基準ではメートル法の使用が義務付けられていたにもかかわらず、品質管理では、外部ソフトウェアのヤード ポンド法の使用に気が付きませんでした。 また、ファイル形式のエラーやその他のバグが原因で、提供されたソフトウェアを使用せずに、計算は手動で行われました。 この状況は、継続的インテグレーションの必要性を示す一例です。

継続的インテグレーションを探求する

継続的インテグレーションは、考え方とチーム戦略です。 これに加えて、著述や講演で知られる Martin Fowler は、継続的インテグレーションとは、多数のチームが作業を頻繁に統合し (通常は各人が少なくとも毎日統合)、1 日あたり複数回の統合を目指すソフトウェア開発方法であると述べています。

各統合は、可能な限り迅速に統合エラーを検出するために、自動ビルド (テストを含む) によって検証されます。

このアプローチを適切に実施することで、プロセスの早い段階で問題が検出されて、統合の問題が軽減されます。

Diagram shows the difference between continuous delivery and continuous deployment. The stages are the same in both cases: code done - unit tests - integrate - acceptance test - deploy to production. For continuous delivery, deployment to production happens manually. For continuous deployment, it's automatic. Continuous integration spans the first three stages for both continuous delivery and continuous deployment.

継続的インテグレーションの目標:

Note

継続的インテグレーションの目標に、継続的コラボレーション、継続的デリバリー、継続的品質がどのように含まれるかに注意してください。

しかし、継続的インテグレーションがない場合はどうでしょうか。 継続的インテグレーションの取り組みが欠如すると、多くの場合、次のようになります。

  • 開発サイクルの長期化
    • コードをコンパイルしない
    • ソース コードが機能しない可能性が常にある
    • コード凍結
  • ビルド エラー/バグの数が増加
    • 実行期間が長い分岐のためにマージ作業に何日もかかる
    • ソース管理でのコードの紛失
    • 開発サイクル後半でのセキュリティの欠陥の検出
    • 大量の技術的負債
    • コード カバレッジ番号がないか少ない
    • 全体的な品質の低下
  • コミュニケーションとコラボレーションの制約
    • コーディング標準に準拠しないコード
    • コード レビューがないか少ない
    • 開発サイクル後半でのテスト
    • 多くのケースで手動 (行われる場合)

統合ポイントは、システムを改善するために使用されるクイック フィードバック ループです。 統合ポイントのタイミングがずれると、プロジェクトに問題が発生します。 Dantar Oosterwal は『The Lean Machine』(リーン マシン) で次のように述べています。

統合ポイントの本質は、それによって製品開発が制御されるということです。 システムを改善する、てこの支点です。 統合ポイントのタイミングがずれると、プロジェクトに問題が発生します。

Dantar Oosterwal、『The Lean Machine』(リーン マシン)

© Scaled Agile, Inc.

チームが実際に継続的インテグレーションを行っているかどうかを考える場合、次の質問は答えを判断するのに役立ちます。

  • すべての開発者がトランクベースの開発を行っていますか?
  • トランクに対する変更ごとに、ビルド プロセスが開始されていますか?
  • ビルドとテストが失敗したとき、チームは数分以内にビルドを修正しますか?

パフォーマンスは、継続的インテグレーションの有無によっても影響を受けます。 Nicole Forsgren、Jez Humble、Gene Kim 共著の『Lean と DevOps の科学 [Accelerate] テクノロジーの戦略的活用が組織変革を加速する』のために収集されて分析されたデータによれば、ロー パフォーマーが市場投入までの速度を上げると品質は低下します。

しかし、ハイ パフォーマーは、市場投入までの速度を上げても品質を保つことができます。 配置サイクルを短縮し (複雑さを軽減し)、継続的インテグレーションを使用して問題をただちに修正して、フローと効率を向上させることができます。

2017 ハイ パフォーマー ミディアム パフォーマー ロー パフォーマー
配置の頻度 1 日あたり複数回 1 週間 - 1 か月 1 週間 - 1 か月
変更のリード タイム <1 時間以内 1 週間 - 1 か月 1 週間 - 1 か月
MTTR <1 時間以内 < 1 日 1 日 - 1 週間
変更失敗率 0 - 15% 0 - 15% 31 - 45%