継続的デリバリー

継続的デリバリーとは、ソフトウェアをいつでも本番環境にリリースできるような方法でソフトウェアを構築するソフトウェア開発手法です。

次のような場合に、継続的デリバリーを行っていると言えます。[1]

• ソフトウェアはライフサイクル全体を通じてデプロイ可能です
• チームは新しい機能の開発よりも、ソフトウェアをデプロイ可能な状態に保つことを優先します
• 誰でも、システムに何らかの変更を加えた際に、システムの本番環境への準備状況に関する迅速な自動フィードバックをいつでも取得できます
• ソフトウェアのどのバージョンでも、オンデマンドで任意の環境にプッシュボタンでデプロイできます

継続的デリバリーは、開発チームによって作成されたソフトウェアを継続的に統合し、実行可能ファイルを構築し、それらの実行可能ファイルに対して自動テストを実行して問題を検出することによって実現されます。さらに、ソフトウェアが本番環境で確実に動作するように、実行可能ファイルを本番環境に近い環境にプッシュします。このために、デプロイメントパイプラインを使用します。

重要なテストは、ビジネススポンサーがソフトウェアの現在の開発バージョンを、予告なしに本番環境にデプロイできることを要求した場合、誰も驚かない、ましてやパニックにならないことです。

継続的デリバリーを達成するには、次のものが必要です。

• デリバリーに関わるすべての人々（多くの場合DevOpsカルチャー[2]と呼ばれます）間の緊密で協力的な作業関係。
• 通常デプロイメントパイプラインを使用して、デリバリープロセスの可能なすべての部分を広範囲に自動化すること。

継続的デリバリーは、継続的デプロイメントと混同されることがあります。継続的デプロイメントとは、すべての変更がパイプラインを通過し、自動的に本番環境に投入されることを意味し、毎日多くの本番環境へのデプロイが発生します。継続的デリバリーは、頻繁なデプロイが可能であることを意味するだけで、ビジネスがより遅いデプロイレートを好むなどの理由で、デプロイしないことを選択することもできます。継続的デプロイメントを行うためには、継続的デリバリーを行っている必要があります。

継続的インテグレーションは、通常、開発環境内でのコードの統合、構築、およびテストを指します。継続的デリバリーは、これを基盤とし、本番環境へのデプロイに必要な最終段階に対処します。

継続的デリバリーの主な利点は次のとおりです。

• デプロイメントリスクの低減：より小さな変更をデプロイするため、問題が発生する可能性が低く、問題が発生した場合でも修正が容易になります。
• 信頼できる進捗：多くの人々は、完了した作業を追跡することで進捗状況を追跡します。「完了」が「開発者が完了したと宣言する」ことを意味する場合、本番環境（または本番環境のような）環境にデプロイされている場合よりも信頼性が低くなります。
• ユーザーフィードバック：ソフトウェアの取り組みにおける最大のリスクは、役に立たないものを構築してしまうことです。実際のユーザーに動作するソフトウェアをより早く、より頻繁に提供することで、それが実際にどの程度価値があるかを判断するためのフィードバックをより早く得ることができます（特に観察された要件を使用する場合）。

ユーザーフィードバックは、継続的デプロイメントを行っていることを必要とします。それが必要だが、新しいソフトウェアをすべてのユーザーベースに提供したくない場合は、ユーザーのサブセットにデプロイできます。最近の私たちのプロジェクトでは、ある小売業者が新しいオンラインシステムをまず従業員に、次に招待されたプレミアム顧客に、そして最後にすべての顧客にデプロイしました。