継続的デリバリー デプロイ モデル
ソフトウェア配信モデルとしての "エピック デプロイ" の多くの欠点について学習しましたが、"うまくいかないこと" を知ることは、道のりの半分にすぎません。 このユニットでは、そのようなモノリシックな方法に代わる手段と、それによって信頼性の向上という目標を達成する方法を学習します。
継続的デリバリーとは
"継続的デリバリー" は、ソフトウェアの変更をより高速で、ストレスが少なく、リスクが低く、より再現性のある方法で使用できるようにする方法です。 継続的デリバリーでは、各ソフトウェアのデプロイや更新をエピック イベントにするのではなく、要求に応じて発生する、迅速かつ定期的で予測可能なエクスペリエンスにすることを目指します。
デプロイの頻度: 継続的デリバリー モデルでは、デプロイは頻繁に行われます。 多くの場合、これは月単位、週単位、日単位、または時間単位になります。 重要なことは、"小規模で焦点を絞った変更を頻繁に" デプロイすることです。
コード コミットによって開始される: ずっと前にスケジュールされるのではなく、コードがコミットされたときにデプロイが行われます。 このコードは、ソフトウェア、インフラストラクチャ、またはソフトウェア構成のようなものである場合があります。
自動テスト: 統合自動テストを使用すると、コードをテストするだけでなく、それらのテストの結果についての迅速なフィードバックを提供することもできます。 この迅速なフィードバックによって、失敗したテストをすばやく反復して復旧できます。
コードのテストが完了したら、テストや QA などの一連のステージング環境で、デプロイをエンドツーエンドでテストできます。 これらの環境全体でのデプロイの展開は、デプロイ エクスペリエンスの統合された部分になります。
履歴レコード: デプロイ活動の履歴レコードだけでなく、運用環境をいつでも調整できるようにする必要があります。 現在の運用環境を作成したデプロイがどれかを理解する必要があります。 この知識があれば、構成、テスト結果、コード自体などを、デプロイをトリガーした個々の pull request までトレースできます。
デプロイの目標
継続的デリバリーのしくみを確認したので、ソフトウェア ソリューションのデプロイにおいて、このような DevOps プラクティスを使用することで達成できる目標について検討します。
目標 1:サービスのデプロイに伴うストレスを軽減すると共に、これらのサービスの信頼性を高める
これはウィンウィンの関係です。ソフトウェアとインフラストラクチャのデプロイに伴うストレスを減らすことで仕事の満足度を高めるだけでなく、システムの信頼性を高めることで、仕事の満足度とエンドユーザーの満足度の両方を高めることができます。 顧客エクスペリエンスへのこのプラスの影響を考えると、厳密に言えば、これはウィンウィンウィンの関係です。
目標 2:変更が必要だとわかったときから、その変更が運用環境にデプロイされるまでの時間を短縮する
たとえば、収益に影響するコードの欠陥を特定したとします。 問題が何であるか、そしてその修正をどのようにコーディングするかは、正確に把握しています。 そのコードを運用環境に適用するまでに、どのくらいの時間がかかるでしょうか。 どれだけの文字列をプルする必要がありますか? どのようにテストしますか。 DevOps プラクティスを使用すると、コード コミットを行い、昼食を取り、デスクに戻る前に、問題が解決されたという通知を受け取ることができます。
目標 3:アイデアが浮かんでから有効なソフトウェアを提供するまでの時間を短縮する
これは先ほどの目標と非常に似ていますが、変更を実装するのではなく、純粋なイノベーションの話です。 イノベーションに対して行動を起こすのに、どのくらいの時間がかかりますか。 このデプロイ モデルを使用すると、新しい概念を実稼働システムに統合し、追加されたイノベーションが現在のシステムを破損させたり妨げたりしないという確信を持つことができます。 この確信があれば、新しい機能を迅速に提供することができます。
デプロイの結果
このユニットで説明した目標は、単なる理論的な願望ではなく、実現可能です。 ここで、DevOps Research and Assessment (DORA) と Google Cloud DevOps & SRE による『2019 Accelerate State of DevOps Report』の統計をいくつか示します。 その中で、"パフォーマンスの高い" DevOps 企業には、以下の特徴があることが発見されています。
- デプロイの回数が 208 倍多い。
- コミットからデプロイまでの時間が 106 倍速い。
- 変更の失敗率が 7 倍低い。
- インシデント復旧時間が 2,604 倍速い。
これはすべて、収益の増加と市場投入までの時間の短縮につながります。
これらの数値は、デプロイ プラクティスが重要であるという考えを証明しています。