生産準備完了はユーザー準備完了ではない

継続的デリバリーは、DevOps を導入する組織にとって最後から 2 番目の目標です。 それは継続的なデプロイメントとなるため、最終的な目標ではありません。

DevOps の世界では、1 日に何度も本番環境対応のソフトウェアを配信する能力に関して、大騒ぎになっています。

それはすばらしい。

私がそれほど興奮しない理由は、DevOps を採用している組織であっても、ほとんどの企業組織では、デリバリーはアプリケーション ライフサイクルの「市場投入」フェーズの最初のステップにすぎないからです。 最終的なビルドとリリースの通知の時点で、ユーザー向けに「準備完了」になっているアプリケーションはほとんどありません。 さまざまな手順とポリシーによってユーザーに適切に配信されるように、本番環境に展開する必要があります。

継続的デプロイメントは、DevOps を採用する組織の究極の目標です (そうあるべきであり、そうかもしれないし、そうなります)。 そうでない場合でも、単に本番環境に配信するだけでは、アプリケーションがその構成要素に「配信」されたことにはならないという大きな問題があります。 これには、企業と消費者の両方のユーザーに最適なアプリケーション エクスペリエンスを提供するために、アプリケーションの拡張、セキュリティ保護、高速化に必要なサービスとともに、本番環境でのデプロイメントが必要です。

それは、スケールと可用性を確保するための負荷分散を意味する可能性があります。 それはほぼ間違いなくセキュリティを意味します。少なくともファイアウォール、できればアプリのセキュリティ、そしておそらくそれ以上のセキュリティです。 アクセスとアイデンティティを意味する場合もあります。 消費者向けアプリの場合はそうではないかもしれませんが、企業向けアプリの場合は、スムーズで簡単なアクセスを確保するために、SSO またはフェデレーション ポリシーに含める必要がある場合があります。 パフォーマンスの面ではスピードも必要になる場合があります。

アプリがユーザーにとって「準備完了」になる前に、これらすべての作業を行う必要があります。 そして「制作」側もそれを知っています。 2017 年のアプリケーション配信の現状に関する調査で「これらのサービスを 1 ～ 10 個導入済み」と回答した 32% のうち、大多数は「5 個以上導入済み」で、63% が現在 6 ～ 10 個導入済みであると回答しました。

「継続的デプロイメント」の問題に関係なく、これらのサービスは、アプリが「本番環境向け」だけでなく「ユーザー向け」であることを保証する上で重要です。

何度も生産に投入することは素晴らしいことですが、より頻繁に市場に投入することが本当の目標です。 DevOps が本番環境に導入されて (さあ、入ってみましょう! 本当に大丈夫です!)、アプリとその直接のインフラストラクチャを処理するようになったとしても、アプリが実際に「配信」されたと見なされる前に、上流のサービスをプロビジョニング、構成、テストする必要があります。

アプリをより頻繁に本番環境にリリースしても、実際には展開スケジュールには影響しません。 オープンソース プロジェクトに「安定」ブランチと「ナイトリー ビルド」オプションがあるのには理由があります。 もちろん、最新かつ最高のものを入手することもできますが、ユーザーとしては「安定した」オプションを好みます。アプリが壊れたり、ランダムにクラッシュしたりすることは、決して良いアプリケーション エクスペリエンスにはつながらないからです。

展開スケジュールはビジネス部門によって決定され、IT 部門によって実装される必要があります。つまり、IT 部門 (4 つのオペレーションすべて) を参加させて、可能な限り多くのプロセスの自動化を開始する必要があります。 アプリは、運用時に周囲のサービスによって保護され、高速化されるため、ユーザーがすぐに使用できる状態になっていません。