In order for you to keep up with customer demand, you need to create a deployment pipeline. You need to get everything in version control. You need to automate the entire environment creation process. You need a deployment pipeline where you can create test and production environments, and then deploy code into them, entirely on demand.

—Erik to Grasshopper, The Phoenix Project

継続的なデプロイメント

継続的なデプロイメント (CD) は、新機能のステージング環境から本番環境への移行を自動化し、リリース可能にする継続的デリバリーパイプラインの側面です。

CDは、継続的デリバリーパイプライン (CDP) を構成する4つの側面、継続的な探索 (CE)、継続的な統合 (CI)、継続的なデプロイメント (CD)、そしてリリースオンデマンドのうちの3つ目です（図1）。

図1 CDPのコンテキストにおける継続的なデプロイメント

ビジネスがリリースオンデマンドをサポートするためのフィーチャーを必要とする前に、フィーチャーは本番環境で利用可能であり、検証済みでなければなりません。したがって、デプロイメントプロセスをリリースから分離して、現在のシステムの動作に影響を与えることなく変更を本番環境に移行できるようにするのが最適です。継続的なデプロイメントは、チームが小規模でインクリメンタルな変更を継続的に本番環境にデプロイすることを可能にします。

継続的にデプロイするケイパビリティは、オンデマンドでリリースするために不可欠です。これにより、アジャイルリリーストレイン (ART) は、持続可能な最短のリードタイムで最高のバリューを持つ市場の機会に対応することができ、新機能の準備ができ次第、顧客が使用できるようになります。

詳細

従来の開発プラクティスでは、デプロイメントとリリースを同じアクティビティとして扱います。このモデルでは、本番にデプロイされた変更は、ユーザーにすぐに利用可能になります。しかし、継続的なデプロイメントは、デプロイメントとリリースのプロセスを分離します。このプラクティスは、以下によりデザイン思考と迅速なバリューフローを促進します。

特定の顧客をターゲットにして機能を提供する – 顧客のターゲットを絞って組織が特定の機能を提供することを可能にし、全ての顧客に機能をデプロイする前に変更の影響をアセスすることができます。
A/Bテストなどの実験を推進する – A/Bテストなどのデザイン思考の実践は、異なる機能を特定のターゲットユーザーに提示し、最適なユーザーエクスペリエンスを作り出すのに役立つフィードバックを集める能力を必要とします。
小規模なバッチの推進 – CDPの自動化（例えば、テスト、構築、デプロイ）は、小規模なバッチでのデプロイを経済的に可能にします。
ビジネスのニーズに基づいてリリースする – デプロイメントプロセスが複雑でエラーが発生しやすい場合、ARTはあまり頻繁にリリースしない傾向があります。自動化と絶え間ないプロセス改善に投資する組織は、高速かつ低リスクでリリースでき、大幅にビジネスアジリティを向上させることができます。例えば、マーケティングキャンペーンの前にリリースを本番環境でデプロイすることができ、組織にバリューのデリバリーの全ての側面を最大限に活用する柔軟性を提供します。

これらのケイパビリティを有効にするために、ARTは継続的なデプロイメントのすべての側面を自動化することにより、変更を本番環境に移す際のトランザクションコストとリスクを減らすことに焦点を当てています。デプロイメントプロセスが繰り返し可能で、予測可能なアクティビティであり、大きな問題がないことを確認することは、チームが継続的なデプロイメントを達成するのに役立ちます。さらに、途切れることのないバリューフローを実現する（原則＃6）ためにデプロイメントを改善することは、ビジネスアジリティを達成するために重要です。詳細はARTフローの記事をご覧ください。

継続的なデプロイメントにおける4つのアクティビティ

図2に示すように、SAFeは継続的なデプロイメントの4つのアクティビティを説明しています。

デプロイ - ソリューションを本番環境にデプロイするための必要なプラクティス
検証 – ソリューションの変更が意図した通りに本番環境で動作することを、顧客にリリースする前に確認するためのプラクティス
モニタリング - 本番環境で発生する可能性があるいかなる問題もモニタリングし報告するためのプラクティス
対応 – デプロイメント中に発生する可能性のある問題に迅速に対応するためのプラクティス

図2 継続的なデプロイメントにおける4つのアクティビティ

デプロイ

デプロイメントは、変更を本番環境に移行することです。 CDPでは、変更のデプロイが継続的に行われます。部分的な機能は、インクリメンタルに本番環境に実装することができます。

あるユーザーストーリーマップに、新しいワークフローを実装するための27のストーリーがあるとします。従来のレガシープラクティスでは、27のストーリーすべてが1つの大きなバッチでデプロイされます。代わりに、個々のストーリーは継続的なデプロイメントとフィーチャートグルを使用して「ダークモード」でデプロイできます。 ARTがすべてのフィーチャーをデプロイすると、ビジネスはそれらをユーザーにリリースするタイミングを選択できます。

理想的には、デプロイメントパイプラインは、構築、統合、および検証が成功した後に自動的にデプロイメントプロセスをトリガーします。このアプローチにより、コードのコミットから本番デプロイまでのワークフローが完全に自動化されたワンクリックプロセスになります。先進の企業では、ピーク時でさえも、確実にデプロイを行うことができます。このアプローチにより、週末や夜間、またはその他の非勤務時間にデプロイに関連する仕事を行う必要がなくなります。

デプロイする能力に貢献するいくつかのプラクティスがあります。

ダークローンチ - 新機能をエンドユーザーにリリースせずに本番環境にデプロイする能力
フィーチャートグル - トグルをコードに実装することでダークローンチを容易にするテクニックで、古い機能と新しい機能を切り替えることが可能になる
デプロイメントの自動化 - テスト済みソリューションをステージングから本番環境に自動的にデプロイする能力
選択的なデプロイメント - 地理、市場セグメントなどの基準に基づいて特定の本番環境にデプロイし、他の環境にはデプロイしない能力
セルフサービスデプロイメント - 自動デプロイメントが部分的に実装されている場合、セルフサービスにより1つのコマンドでソリューションをステージングから本番環境に移動させることが可能になる
バージョン管理 - 環境をバージョン管理することで、迅速なデプロイとリカバリーが可能になる
ブルー/グリーンデプロイメント - ステージング環境と本番環境間でのデマンドに応じた切り替えを可能にするテクニック

検証

エンドユーザーにリリースする前に、機能面での整合性と堅牢性について、デプロイメントを検証する必要があります。これら2つのプロセスは、密結合しているとほぼ同時に発生し、リカバリーの判断が主要な懸念事項になります。ただし、それらが分離されている場合、リリースを承認する前に、新機能を本番環境において広範囲にテストする余地があります。本番への移行後、ソリューションは最終ラウンドのテストを受けます。通常、これにはスモークテスト、簡単なユーザー受け入れテスト、およびストレスとパフォーマンステストが必要で、これらは本番環境で行われなければなりません。この検証は、実際の本番ソリューションコンテキストでのソリューションの動作をテストするための必要な健全性確認を提供します。

継続的な統合により、ソリューションが本番環境で予想通りに動作することがほぼ確実になります。しかし、予想外の事態も発生します。検証によって重大な欠陥が明らかになった場合、本番環境を損なったりビジネスフローを妨げたりするのを防ぐために、デプロイメントのロールバック、または迅速な修正が必要となります。

デプロイメント後の検証を促進する4つのプラクティスがあります。

本番環境テスト - フィーチャートグルまたは「ダーク」ローンチを使用して、本番環境のソリューションをテストする
テスト自動化 - テストを自動化し、迅速かつ繰り返し実行する能力
テストデータ管理 - バージョン管理でテストデータを管理し、自動テストの一貫性を確保する
非機能要件 (NFR) のテスト - チームは、セキュリティ、信頼性、パフォーマンス、拡張性、およびユーザビリティなどのシステム属性もテストして、NFRが品質基準を満たしていることを確認する

モニタリング

デプロイされたフィーチャーが本番に移行しても問題なく動作することを確認することは、リリース前に欠かすことのできない品質チェックです。ただし、チームは、フィーチャーのパフォーマンスとバリューをその存続期間全体で測定できることも確認しなければなりません。この重要なフィードバックループを可能にする洞察は、主に堅牢なモニタリングケイパビリティから得られ、リリース前には必ず導入しておく必要があります。

効果的なモニタリングには、CDPを通じてデプロイされたすべてのフィーチャーに対してフルスタックの遠隔測定がアクティブであることが必要です。この遠隔測定は、チームがシステムのパフォーマンス、エンドユーザーの動作、インシデント、およびビジネスバリューを本番中に迅速かつ正確に確認することを可能にします。収集されたデータは、各フィーチャーのトラッキングとモニタリングを提供し、提供されるビジネスバリューの分析の精度を高め、本番環境の問題に対する反応性を向上させます。

チームがビジネスバリューメトリクスの一部をリリース時まで収集できない場合でも、リリース決定が発生する前に測定値を取得する方法を知る必要があります。これをサポートするプラクティスには以下のようなものがあります。

フルスタック遠隔測定 - システムがカバーする全スタックにわたる問題をモニタリングする能力
視覚表示 - 自動測定を表示するツール
連携モニタリング - ソリューション内のアプリケーション全体で統合されたモニタリングは、問題とパフォーマンスの全体的な視点を提供する

メジャー＆グローの記事では、モニタリングに必要なメトリクスの種類についてのガイダンスを提供しています。

対応

予期せぬ本番の問題に対応し、リカバリーする能力は、継続的なデプロイメントをサポートし、CDPを効率化する上で重要です。その理由は明らかです。

本番の問題は直接顧客とエンドユーザーに影響を与えるため、問題が発生するとデプロイされたソリューションのバリューがすぐに低下する可能性があります。
本番の問題により、修正、パッチ、再開発、再テスト、再デプロイなどのやり直しが発生します。それは、パイプラインを通じた通常のバリューフローを妨げます。

本番の問題がデリバリーの効率を損ない、バリューを下げる可能性があるため、チームは問題を積極的に検出し、迅速に回復する能力が必要です。平均修復時間 (MTTR) で測定されるように、迅速なリカバリーは、高いDevOps成熟度の最も信頼性の高い先行指標の一つです[5]。リカバリーは、DevOpsに対するSAFeのCALMRアプローチの5つの要素のうちの1つでもあります。

対応とリカバリーの目標は、潜在的な問題をインシデントになる前に特定し、それらがビジネスのオペレーションに影響を与えるのを防ぐことにあります。この能力は、エンドユーザーがそれらを発見する前に内部で問題を検出し、迅速に根本原因を特定し、練習を重ねた手順でサービスを復旧することを必要とします。対照的に、システムを稼働し続けるためだけに直接本番システムに性急に事後的な変更を加えることは、環境間でのソースコードと構成の相違、未確認の変更、そして長期的なリスクを招きます。

本番環境で発生した問題の対応とリカバリーの能力をサポートするプラクティスには次のものがあります。

プロアクティブ検出 - ソリューションに積極的に欠陥を作り出して、問題や状況が発生する前にそれらを特定するテクニックです。例えば、Netflixが開発したChaos Monkey [1] は、エンジニアがインスタンスの障害に対して耐性を持つようにサービスを実装することを確認するために、本番環境でランダムにインスタンスを終了するオープンソースのツールです。
チーム間のコラボレーション - バリューストリーム全体で問題が発生した時に、それを特定し解決するために協力するマインドセットです。
セッションの再生 - エンドユーザーのセッションを再生してインシデントを調査し、問題を特定する能力です。
ロールバックとフィックスフォワード - ソリューションを前の環境に素早くロールバックする能力、またはロールバックする必要なくパイプラインを通じて問題を素早く修正する能力です。
不変のインフラストラクチャ - この概念は、デプロイメント後にサーバーや仮想マシン (VM) を一切変更しないことを指します。代わりに、何かを更新する必要がある場合、適切な変更を加えたイメージから新しいサーバーが構築されます。
バージョン管理 - 環境は、迅速なロールバックを可能にするためバージョン管理の下で維持されます。

フィーチャーが本番環境に成功裏にデプロイされ、継続的なバリューを追跡し管理するための必要なモニタリングとリカバリーケイパビリティがあることをチームが実証すると、CDPの継続的なデプロイメントステージを完了したことになります。これにより、企業は必要に応じていつでもリリースできるようになります。

DevOpsによる継続的なデプロイメントを可能にする

継続的なデプロイメントは、DevOpsの「Ops」に頻繁に関連する重要なオペレーションアクティビティを含みます。ソリューションを本番環境にデプロイし、その機能の整合性を確認し、効果的なモニタリングとリリース後のサポートを確保することに焦点を当てています。

図3では、DevOps (中央) といくつかの実践分野 (内側の輪) に対するSAFeのCALMRアプローチが継続的なデプロイメントを可能にする様子を示しています。 4つのアクティビティ (緑色) のそれぞれは、デリバリーの速度と品質を最大化するために、複数の分野からのDevOpsの専門知識を活用する共同作業です。

図3 DevOpsは継続的なデプロイメントを可能にする

例えば、CDPでソリューションをデプロイするには、本番環境のインフラストラクチャのプロビジョニングを自動化し、選択したターゲットにソリューションのバイナリをデプロイし、本番環境の機能を確認し、ランタイムの遠隔測定を捕捉し、問題に対して積極的に警告するツールを使用することが含まれます。 DevOpsの実践とツールは、これらのケイパビリティを効率化し、ソリューションをデプロイし、数分でオンデマンドリリースに完全に対応できるようにします。

4つのすべての継続的なデプロイメントのアクティビティはDevOpsによって可能になりますが、技術的な実践とツールの組み合わせは異なります。 DevOpsとそれがCDPをどのように促進するかについての詳細なガイダンスについては、DevOpsの記事シリーズをご覧ください。

詳しく学ぶ

[1] https://netflix.github.io/chaosmonkey/

[2] Kim, Gene, et al. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. IT Revolution Press, 2013.

[3] Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press, 2016.

[4] Humble, Jez, and David Farley. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley, 2010.

[5] Gregory, Janet, and Lisa Crispin. More Agile Testing: Learning Journeys for the Whole Team. Addison-Wesley Signature Series (Cohn). Pearson Education, 2014.

[6] State of DevOps Report. https://puppet.com/resources/whitepaper/state-of-devops-report

最終更新： 2023年1月9日