継続的デリバリー

継続的デリバリー（CD）は、チームが短いサイクルでソフトウェアを作成し、ソフトウェアがいつでも確実にリリースできるようにするソフトウェアエンジニアリングのアプローチです。 ^{[1] [2]}これは、ソフトウェアをより迅速かつ頻繁に構築、テスト、リリースすることを目的としています。このアプローチは、運用中のアプリケーションに対してより多くの増分更新を可能にすることで、変更を配信するコスト、時間、^[要出典]、およびリスクを削減するのに役立ちます。継続的デリバリーには、簡単で反復可能なデプロイメントプロセスが重要です。

継続的デリバリーは、デプロイメントパイプライン^[3]という一般的な概念を、リーン ポカヨケ^[4]として扱います。これは、ソフトウェアがリリースに至るまでに通過しなければならない一連の検証です。コードは必要に応じてコンパイルされ、変更がソース管理リポジトリにコミットされるたびにビルドサーバーによってパッケージ化され、その後、さまざまな手法（手動テストを含む場合もある）でテストされてから、リリース可能としてマークされます。

長いサイクル タイムに慣れている開発者は、CD 環境で作業するときに考え方を変える必要があるかもしれません。コード コミットはいつでも顧客にリリースされる可能性があります。フィーチャー トグルなどのパターンは、エンド ユーザーが使用できる状態にまだなっていないコードを早期にコミットするのに非常に役立ちます。NoSQL を使用すると、データ移行やスキーマ変更の手順、多くの場合は手動の手順や継続的デリバリー ワークフローの例外を省くことができます。^[5]コード ブランチングなどのコードを分離して開発するための他の便利な手法は、CD の世界では時代遅れではありませんが、CD の原則に合うように適応させる必要があります。たとえば、複数の長期コード ブランチを実行することは非現実的である可能性があります。これは、パイプラインのすべてのフェーズを通過するには、CD プロセスの早い段階で単一のコード ブランチからリリース可能な成果物を構築する必要があるためです。^{[説明が必要]}

継続的デリバリーはデプロイメントパイプラインを通じて可能になります。デプロイメントパイプラインの目的には、可視性、フィードバック、継続的なデプロイメントという3つの要素があります。^[6]

• 可視性– 構築、展開、テスト、リリースを含む配信システムのすべての側面がチームのすべてのメンバーに見えるため、コラボレーションが促進されます。
• フィードバック- チームメンバーは、問題が発生したときにできるだけ早くそれを把握し、できるだけ早く解決できるようにします。
• 継続的な展開- 完全に自動化されたプロセスを通じて、あらゆるバージョンのソフトウェアをあらゆる環境に展開およびリリースできます。

Yan Cui氏によると、サーバーレス環境 の場合、高い凝集性を実現するために、一時的なリソースはまとめて保管し、独自のデプロイメントパイプラインを持つ必要があるとのこと。ただし、スピンアップ時間とランディングゾーンが長い共有リソースには、独自のリポジトリ、デプロイメントパイプライン、スタックが必要です。^[7]

継続的デリバリーは、ソース管理から本番環境まで自動化を実現します。このプロセスのすべてまたは一部を実行するのに役立つさまざまなツールがあります。^[8]これらのツールは、継続的デリバリーを含むデプロイメントパイプラインの一部です。プロセスのさまざまな部分を実行するツールの種類には、継続的インテグレーション、アプリケーションリリース自動化、ビルド自動化、アプリケーションライフサイクル管理などがあります。^[9]

継続的デリバリーを効果的に実践するには、ソフトウェアアプリケーションが、展開可能性、変更可能性、テスト可能性などの一連のアーキテクチャ上重要な要件（ASR）を満たす必要があります。 ^[10]これらのASRには高い優先度が必要であり、軽々しくトレードオフすることはできません。

マイクロサービスは、継続的デリバリーの設計時によく使用されます。^[11]マイクロサービスを使用すると、ソフトウェアシステムの展開可能性と変更可能性を高めることができます。確認されている展開可能性の向上には、展開の独立性、展開時間の短縮、展開手順の簡素化、ダウンタイムゼロの展開などがあります。確認されている変更可能性の向上には、小さな増分機能変更のサイクルタイムの短縮、テクノロジー選択の変更の容易化、品質属性の増分変更、言語とライブラリのアップグレードの容易化などがあります。^[11]

ジェズ・ハンブルとデビッド・ファーリー（2010年）が書いたオリジナルのCDブックがこの用語を普及させましたが、その定義は作成以来進歩し続け、今ではより発展した意味を持っています。今日の企業はこれらの継続的デリバリーの原則とベストプラクティスを実装しています。医療とWebなどのドメインの違いは依然として重要であり、実装と使用に影響を与えます。^[12]このアプローチを採用している有名な企業には、Yahoo!、^[13] Amazon、^[14] Facebook、^[15] Google、^[16] Paddy Power ^[1]、Wells Fargoなどがあります。^[17]

継続的デリバリーにはいくつかの利点があることが報告されている。^{[1] [12]}

• 市場投入までの時間の短縮: 継続的デリバリーにより、組織は新しいソフトウェア リリースに内在するビジネス価値をより迅速に顧客に提供できます。この機能により、企業は競合他社より一歩先んじることができます。
• 適切な製品の構築: 頻繁なリリースにより、アプリケーション開発チームはユーザーからのフィードバックをより迅速に得ることができます。これにより、有用な機能のみに取り組むことができます。機能が役に立たないことが判明した場合、その機能にはそれ以上の労力を費やしません。これにより、適切な製品を構築できます。
• 生産性と効率性の向上: 自動化により、開発者、テスト担当者、運用エンジニアなどの時間が大幅に節約されます。
• 信頼性の高いリリース: リリースに関連するリスクが大幅に減少し、リリース プロセスの信頼性が向上しました。継続的デリバリーでは、デプロイメント プロセスとスクリプトは、本番環境にデプロイする前に繰り返しテストされます。そのため、デプロイメント プロセスとスクリプトのほとんどのエラーはすでに発見されています。リリース頻度が上がると、リリースごとのコード変更の回数が減少します。これにより、発生した問題を簡単に見つけて修正できるようになり、問題が影響を及ぼす時間が短縮されます。
• 製品品質の向上: 未解決のバグや製造インシデントの数が大幅に減少しました。
• 顧客満足度の向上: より高いレベルの顧客満足度が達成されます。

障害物についても調査が行われた。^[12]

• 顧客の好み: システムの頻繁な更新を望まない顧客もいます。
• ドメイン制限: 通信、医療、航空電子工学、鉄道、重工業などの一部のドメインでは、規制により、新しいバージョンの顧客側またはオンサイトでのテストが義務付けられています。
• テスト自動化の欠如: テスト自動化の欠如は開発者の信頼の欠如につながり、継続的デリバリーの使用を妨げる可能性があります。
• 環境の違い: 開発、テスト、本番環境で使用される環境が異なると、検出されない問題が本番環境に紛れ込む可能性があります。
• 人間のオラクルを必要とするテスト: すべての品質属性を自動化で検証できるわけではありません。これらの属性には人間の介入が必要であり、配信パイプラインの速度が低下します。

Chen氏はさらに8つの採用上の課題を挙げ、詳しく説明しました。^[18]これらの課題は、組織構造、プロセス、ツール、インフラストラクチャ、レガシーシステム、継続的デリバリーのためのアーキテクチャ、非機能要件の継続的テスト、テスト実行の最適化の分野にあります。

継続的デリバリーの導入における課題を克服するためのいくつかの戦略が報告されている。^[18]

以下のプラクティスは、特にクラウドでホストされているシステムにおいて、パイプラインの生産性を向上させることができます。^{[19] [20] [21]}

• パイプラインの数: 小規模なチームでは、リポジトリとパイプラインを 1 つずつ持つことで生産性を高めることができます。対照的に、大規模な組織では、チームごとに個別のリポジトリとパイプラインを持つ場合や、チーム内のサービスごとに個別のリポジトリとパイプラインを持つ場合もあります。
• 権限:パイプライン関連の権限に関しては、アーキテクチャの動的な性質により、最小権限の原則を順守することが困難な場合があります。管理者は、爆発半径を最小限に抑えるために補償セキュリティ制御を実装しながら、より許容度の高い権限を選択できます。

DevOpsは、文化の変化、特にソフトウェア配信に関わるさまざまなチーム（開発者、運用、品質保証、管理など）のコラボレーションと、ソフトウェア配信のプロセスの自動化を中心としたソフトウェアエンジニアリングのアプローチです。^{[22] [23] [24]}

継続的デプロイメントは、自動化されたソフトウェアデプロイメントを使用するソフトウェアエンジニアリングアプローチです。^[18] このアプローチでは、ソフトウェアは短いサイクルで生産されますが、最後のステップで「ボタンをクリックする」必要はなく、生産に至るまで自動化されたソフトウェアデプロイメントを通じて生産されます。 ^{[1] :  52}したがって、継続的デプロイメントは、より洗練された形式の自動化と見なすことができます。^[25] 学術文献では、継続的デリバリーと継続的デプロイメントを、デプロイメント方法（手動と自動）に応じて区別しています。^{[2] [26]}

• Humble, Jez; Farley, David (2010)。継続的デリバリー: ビルド、テスト、デプロイメントの自動化による信頼性の高いソフトウェアリリース。Addison- Wesley。ISBN 978-0-321-60191-9。
• Wolff, Eberhard (2017)。継続的デリバリーの実践ガイド。Addison- Wesley。ISBN 978-0-134-69147-3。

• 継続的デリバリーの実践^[1]