継続的デリバリー デプロイ モデル

ソフトウェア配信モデルとしての "エピックデプロイ" の多くの欠点について学習しましたが、うまく機能 しない ものを知ることは戦いの半分にすぎません。 このユニットでは、そのモノリシックメソッドの代替方法と、信頼性向上の目標をさらに高める方法について説明します。

また、同じ意味で使用される場合がある 2 つの関連用語を区別する価値もあります。

• 継続的デリバリー: 自動テストに合格するすべての変更を運用環境にデプロイする 準備はできました が、実稼働への実際のリリースは手動承認によって制限されます。
• 継続的デプロイ: 自動テストに合格するすべての変更は、手動ゲートなしで 運用環境に自動的 にリリースされます。

どちらも同じ基礎 (頻繁な統合、自動テスト、反復可能なパイプライン) に依存します。 このモジュールでは、これらの共有基盤に焦点を当てます。

継続的デリバリーとは

継続的デリバリー は、コードベースに対するすべての変更を、より速く、ストレスが少なく、リスクが低く、再現可能な方法で リリース可能 な状態に保つ方法です。 各ソフトウェアの展開やエピック イベントの更新を行うのではなく、継続的デリバリーによって、オンデマンドで発生する迅速で日常的な予測可能なエクスペリエンスに変わります。

• デプロイの頻度: 継続的デリバリー モデルでは、デプロイは頻繁に行われます。 ケイデンスは、月単位、週単位、日単位、または 1 時間単位でもかまいません。 重要なことは、"小規模で焦点を絞った変更を頻繁に" デプロイすることです。

• コード コミットによってトリガーされる: リリース ウィンドウが事前にスケジュールされるのを待つ代わりに、コードがコミットされたときに配信パイプラインが開始されます。 このコードは、ソフトウェア、インフラストラクチャ、またはソフトウェア構成のようなものである場合があります。 その後、各変更がビルドされ、テストされ、リリースの準備が整います。 組織の管理体制によっては、承認後も運用環境への昇格が行われる可能性があります。

• 自動テスト: 統合自動テストを使用すると、コードをテストするだけでなく、それらのテストの結果についての迅速なフィードバックを提供することもできます。 この迅速なフィードバックによって、失敗したテストをすばやく反復して復旧できます。

  コードのテストが完了したら、テストや QA などの一連のステージング環境で、デプロイをエンドツーエンドでテストできます。 これらの環境全体でのデプロイの展開は、デプロイ エクスペリエンスの統合された部分になります。

• 履歴レコード: デプロイ活動の履歴レコードだけでなく、運用環境をいつでも調整できるようにする必要があります。 現在の運用環境を作成したデプロイがどれかを理解する必要があります。 この知識があれば、構成、テスト結果、コード自体などを、デプロイをトリガーした個々の pull request までトレースできます。

展開目標

継続的デリバリーのしくみを把握したら、ソフトウェアソリューションをデプロイする際に達成される目標について考えてみてください。これは、継続的デリバリーやその他の DevOps プラクティスが実現を助けます。

目標 1:サービスのデプロイに伴うストレスを軽減すると共に、これらのサービスの信頼性を高める

ソフトウェアとインフラストラクチャのデプロイのストレスを軽減することで、それらを実行するエンジニアの日常のエクスペリエンスが向上します。 その結果、信頼性が向上すると、停止や中断が少なくなるエンド ユーザーにもメリットがあります。

目標 2:変更が必要だとわかったときから、その変更が運用環境にデプロイされるまでの時間を短縮する

たとえば、収益に影響を与えるコードの欠陥を特定し、その修正方法を正確に把握したとします。 成熟した DevOps プラクティスでは、コミットから運用環境へのパスは短く、予測可能です。 変更はビルドされ、関連する環境全体で自動的にテストされ、数分以内にリリース用に準備されます。 必要な承認が与えられると、将来のリリース予定を待たずに、運用環境に移行することができます。

目標 3: アイデアを持ち、使用可能なソフトウェアを提供する時間を短縮する

この目標は前の目標と似ていますが、修正ではなくイノベーションに重点を置いています。 新しいアイデアに基づいて行動するのにどのくらいの時間がかかりますか? このデプロイ モデルを使用すると、新しい概念を運用システムに統合できます。これにより、追加によって現在のシステムが中断されたり妨げたりすることはありません。 これにより、新機能を迅速に提供できます。

デプロイの結果

このユニットで説明する目標は、理論上の願望だけではなく、測定可能です。 2014 年以降、DevOps Research and Assessment (DORA) チームは、ソフトウェア配信のパフォーマンスに関する毎年の DevOps の状態調査を発表しています。 近年、この作品は DevOps の加速状態レポートとして発行されています。 現在の DORA モデルでは、次の 5 つの配信メトリックが追跡されます。

• デプロイの頻度
• リード タイムの変更
• 失敗率の変更
• デプロイ失敗の復旧時間
• デプロイの再作業率

毎年、この調査では、パフォーマンスの高いチームがより頻繁に変更を提供し、コミットから運用環境に迅速に移行し、失敗したデプロイから迅速に復旧し、デプロイ関連の問題の修正に費やす時間を短縮することが示されています。 最新の調査とメトリックの定義については、 DORA のソフトウェア配信メトリックを参照してください。

これらの結果は、デプロイプラクティスが重要であるという考えを検証します。