NetOps が継続的デプロイメントを採用する時が来ました

継続的なデプロイメントでは、すべての変更を毎回すぐに実行する必要はありません。 しかし、どこかで始めなければなりません。

CI/CD (継続的インテグレーション/継続的デリバリー) は開発者の領域です。 これは、配信のスピードを向上させるための包括的なモデルであり、よりアクティブなユーザー関連のコンテキストでこれを見ることに慣れている人にとっては、実際には「展開の準備が整っている」ことを意味します。

これは、NetOps が CI/CD を無視できるという意味ではありません。むしろその逆です。 しかし、NetOps が 1:1 の展開と配信の比率を維持する必要があるという意味ではありません。 アプリが「展開準備完了」になる頻度は、アプリ開発者が継続的デリバリーの技術を完璧に習得している場合、特に NetOps が継続的展開の技術をまだ完璧に習得していない場合は、圧倒的になる可能性があります。  しかし、より高い頻度でのデプロイメントに対応する余地があり、場合によっては、開発者やビジネスにとって継続的なデプロイメントのような効果が得られる可能性があります。 

その秘密は、アプリに対する「マイナーな変更」と「メジャーな変更」の違いにあります。

NetDevOps 2016 年秋の調査では、私たちがよく考えるよりもはるかに高い頻度で、マイナーな変更が本番環境に導入されていることがわかりました。 回答者の約 51% が、1 日に 1 回以上、マイナーな変更を本番環境に導入しています。 3 人に 1 人以上が、月に 1 回から 5 回の主要な変更を推進しており、残りの 3 分の 1 は、月に 1 回未満の主要な変更を行ったと告白しています。

残念ながら、「主要な」変更と「小さな」変更の定義は定量化されていませんが、通常の場合と同様に、このような相対的な記述は、業界や組織だけでなく、各アプリケーションに固有のものであることがよくあります。 それでも、かなりの数（半数強）の企業が、生産に大規模な変更を定期的に導入しているようです。

つまり、大きな計画の中で、継続的なデプロイメントに向けて小さな一歩を踏み出していることになります。 問題は、新しいアプリケーションを展開することと、既存のアプリケーションに更新を展開することとは異なるということです。 新しいネットワークやアプリ サービスを追加する場合でも、「混乱の可能性」の規模ではまったく新しいアプリケーションを展開する場合とは大きく異なります。

したがって、今のところ、新しいアプリにはより多くの調整と計画が必要になると言えます。 継続的なデプロイメントの潜在的なターゲットとして、運用中のアプリの大部分が依然として残っています。 私たちがそれを奨励できることの 1 つは、実稼働環境への影響に関して、「マイナー」な変更と「メジャー」な変更について何らかのコンテキストを設けることです。

軽微な変更は、アプリに内部的に影響を及ぼすものに限定される場合があります。 たとえば、ロジックの変更などです。 これらには、アプリ スタック (Web サーバー、アプリ サーバーなど) へのパッチやアップグレード、およびそれをサポートするアプリインフラストラクチャへのパッチやアップグレードが含まれる場合があります。 基本的に、軽微な変更はアプリにのみ影響します。通常の使用で実際にアプリを配信および保護するネットワークやアプリ サービスに変更を加える必要はありません。

大きな変更とは、ネットワークやアプリをサポートするアプリ サービスに影響を及ぼす変更のことです。大きな変更には、配信ポリシーの調整 (圧縮を有効にするなど) や、最近発見された脆弱性の悪用を防ぐための URL フィルタリングやリクエスト検査などの新しいサービスの挿入が必要になる場合があります。 これらは、より広範な生産システムに影響を及ぼし、それが他のアプリケーションに影響を及ぼすかどうかわからないという点で、大きな変更です。

外部サービスへの影響を考慮した、より微妙なスコアリング システムを策定する場合もあります。 新しいサービスは、既存のサービスの調整よりも混乱を招く可能性があります。 新しいポリシーの実装には、小さな更新を含む既存のポリシーよりも多くの注意が必要です。

使用する「システム」について合意したら、オンデマンドで小さな変更を有効にすることに同意するのがはるかに簡単になります。 本質的には、何か問題が発生した場合の潜在的な影響が最小限であると考えられる限り、アプリの配信を本番環境に流すことによって、継続的なデプロイメントに移行します。 小さな変更、小さなリスク。 少なくとも、それは仮定です。

これにより、大きなビジネス上の変更となる可能性のある小さな技術的変更を、より早くユーザーに提供できるようになります。 なぜなら、それらは大規模で伝統的な組織でしばしば妨げられるからです。 ユーザー インターフェイスへの小さな変更であっても、スケジュールの競合や、プロジェクトの優先順位や方針に基づく変更管理委員会の決定により、数週間、あるいはそれ以上遅延される可能性があります。 その小さな変更が、ユーザー エクスペリエンスの向上につながり、コンバージョン率や顧客維持率の向上につながる可能性もあります。 その小さな変更がアプリにのみ影響する場合、つまり「マイナー」な変更である場合、IT のポリシーがそれを延期する理由になるのでしょうか?

継続的デプロイメントは、技術的に本番環境への自動プッシュを可能にするだけでなく、アプリケーションと更新が本番環境にいつ導入されるかを決定するプロセスを遅らせる従来の構造を破壊することも意味します (これが文化です)。

「マイナー」アップデートと「メジャー」アップデート、つまりアプリ外部のシステムに影響を与える可能性のあるアップデートとそうでないアップデートを区別するための共通基準を確立することで、組織は追加のリスクを負ったり本番環境を不安定にしたりすることなく、一部の変更を継続的に展開できるようになります。 そして、それはビジネスにプラスの影響を与える可能性があり、それは誰もが勝利することを意味します。