継続的デリバリーを使用しコストとリスクを抑えて迅速にリリースする

完了

継続的デリバリーは、DevOps 分類の 8 つの機能の 1 つです。

継続的デリバリーが必要な理由を探す

2012 年、ソフトウェアの配置エラーのために、当時の米国最大手の証券会社 Knight Capital Group が 4 億 6000 万ドルの損失を被りました。

損失は市場の開始と同時に始まりました。 コードにバグはありませんでした。この問題は、8 台の運用サーバーに手動で配置した際に 1 台のみのエラーによって引き起こされました。

修正を試みたことで、8 台のサーバーすべての構成がおかしくなり、損失がさらに大きくなりました。 すべての配置は手動で行われたため、変更を自動的にロールバックする方法はありませんでした。

問題の修正を 45 分間試みた後で、最終的にシステム全体をシャットダウンしました。 その間に 4 億 6000 万ドルが失われていました。

これは実際の話です。 あなたの組織にどのような影響があるでしょうか。 手動で配置していますか。

おそらく、組織のデリバリー パフォーマンスを理解するために役立つ 1 つの重要な質問は次のものです。

重要

運用環境への配置の負担はどれくらい大きいですか?

エンジニアや技術スタッフがコードを運用環境に導入するときに感じる恐れや心配によって、チームのソフトウェア デリバリー パフォーマンスについて多くのことがわかります。

継続的デリバリーとは

重要

継続的デリバリーとは、チームが短時間でソフトウェアを開発するソフトウェア エンジニアリング アプローチです。これにより、ソフトウェアに関して以下が実現します。

  • 常に確実なリリース
  • 手動でのリリース

継続的デリバリーの目的は次のとおりです。

  • ソフトウェアを、よりすばやくより頻繁に、ビルド、テスト、リリースします。
  • 運用環境でのアプリケーションのインクリメンタル型更新を可能にすることで、変更を提供するコスト、時間、リスクを軽減します。

継続的デリバリーが実現するのは次の場合です。

  • ライフサイクルを通じてソフトウェアの配置を行うことができます。
  • デリバリー プロセスのすべての部分で、継続的インテグレーションと広範な自動化を利用できます (通常は配置パイプラインを使用)。
  • 任意のバージョンのソフトウェアを、要求時に、ボタンを押すようにして任意の環境に配置できます。

図は、継続的デリバリーと継続的配置の違いを示しています。これらのステージは両方のケースで同じです。コードの作成 - 単体テスト - 統合 - 受け入れテスト - 運用環境への配置。継続的デリバリーでは、運用環境への配置が手動で行われます。継続的配置の場合は自動です。

大規模な手動配置では、リリースされるソフトウェアが大幅に複雑になり、人的エラーの可能性が生じ、配置の失敗を特定して修正することが難しくなり、リスクが高くなります。 展開の頻度が低く、変更のリード タイムが長く、平均回復時間が長く、変更の失敗率が上がります。

指定された運用チームが、営業時間外に手動配置を実行します。 手動の手順のドキュメントと、ドキュメント化された手順を手動でテストする時間が必要です。 大規模な配置では、実行する時間も長くなり、失敗時のロールバックも難しくなります。また、配置後に行うテストのスコープも大きくなります。 配置ごとの変更の数が多くなると、フィードバックを実装する時間がさらに長くなります。

プロセスが自動化され、いつでも運用環境にリリースできるようになることで、継続的デリバリーの利点は、次のように多数あり大きな影響力があります。

図は、継続的デリバリーを円として示しています。サイクルは、計画と追跡から、開発、ビルドとテスト、配置、運用、監視、学習に進み、計画に戻ります。

2019 年の State of DevOps Report レポートによれば、高いパフォーマンスの DevOps 組織は、ロー パフォーマーと比較して以下を達成しています。

  • 配置の頻度が 200 倍超
  • 変更のリード タイムの短縮が 100 倍超
  • 平均回復時間の短縮が 2600 倍超
  • 変更の失敗率の低下が 7 倍

また、CA Technologies による世界規模の調査によれば、組織は、市場投入までの時間短縮および収益増に関して最大 20% の改善を実現しています。

図は、ロー パフォーマーに比べて、高パフォーマンス DevOps の組織が継続的デリバリーを使用する利点を示しています。

Note

継続的デリバリーが継続的配置と混同されることがあります。 継続的配置は、すべての変更がパイプラインを通過して自動的に運用環境に提供され、結果として運用への多数の配置が毎日行われることを意味します。 継続的デリバリーは、頻繁な配置を行えるが、行わないことも選べることを意味します(通常は、低頻度での配置が業務に適しているという理由)。 継続的配置を行うには、継続的デリバリーを行う必要があります。

継続的インテグレーションは継続的デリバリーの前提条件です。 採用されているプラクティスによって、いつでも高い品質での、アプリケーションのビルドとソース管理からの (確実な) 配置が実現します。

図は、継続的インテグレーション、継続的デリバリー、継続的インテグレーションの関係を示しています。