拡張リリースで展開リングを使用する

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

展開リングを使用すると、ユーザーへの影響を制限しながら、運用環境で拡張機能への変更を段階的にデプロイして検証できます。

すべてのユーザーが変更に公開される、すべての運用環境に同時にデプロイすることはお勧めしません。 段階的なロールアウトでは、時間の経過と共にユーザーが変更を受け取り、運用環境の変更をより少ないユーザーで検証します。

次の表は、リングを使用している場合とリングがない場合の影響を受ける領域の違いを示しています。

リングなし	影響を受ける領域	リング付き
手動でエラーが発生しやすい	Build	自動化され、一貫性のある
手動でエラーが発生しやすい	リリース	自動化され、一貫性のある
時間	ビルド時間 (T TB (テラバイト))	秒
日	リリースまでの時間 (TTR)	分
ユーザーからの呼び出し	問題の検出	プロアクティブ
曜日から週	問題の解決	分から日

詳細については、「安全なデプロイのためのリリース パイプラインの構成」を参照してください。

前提条件

• リリースのパイプラインと承認機能の詳細なドキュメントについては、CI/CD パイプラインと承認を確認してください。

ユーザーの種類を割り当てる

ユーザーの種類ごとに最適なユーザーを決定します。 各レベルでフィードバックを提供する機会とリスク レベルを伝えます。これは、期待を設定し、成功を確実にすることが重要であるためです。 次の例では、ユーザーは運用環境で 3 つのグループに分けられます。

• カナリア: 利用可能になるとすぐに、自発的に機能をテストします。
• 早期導入者: 自発的にリリースをプレビューし、カナリア ビットよりも洗練されていると見なされます。
• ユーザー: カナリアと早期導入者を通過した後、製品を使用します。

トポロジのマップ

拡張機能のトポロジを呼び出し可能なデプロイ モデルにマップして、変更がユーザーに与える影響を制限し、価値を提供します。 オープンソースコミュニティ拡張機能の場合、ほとんどの場合、リングベースのデプロイを使用して、カナリア、早期導入者、およびユーザーに新しいリリースを段階的に公開します。

アプリケーション レベルでは、Azure DevOps 拡張機能の構成は、個別に簡単にダイジェスト、スケーリング、デプロイできます。

各拡張機能は、次のタスクを実行します。

• その他の Web ファイルとスクリプト ファイルの 1 つがある
• コア クライアントとのインターフェイス
• REST クライアント API と REST API を使用したインターフェイス
• キャッシュまたは回復性のあるストレージに状態を保持する

インフラストラクチャ レベルでは、拡張機能が Marketplace に 公開されます。 組織に拡張機能をインストールすると、Azure DevOps サービス ポータルによってホストされ、状態は Azure Storage または拡張機能 データ ストレージに保持されます。

拡張トポロジは、リング デプロイ モデルに完全に適しており、各デプロイ リングに拡張機能を発行します。

• カナリア リングのプライベート開発バージョン
• 早期導入者リングのプライベート プレビュー バージョン
• ユーザーリングのパブリック運用バージョン

ヒント

招待されたユーザーへの公開を制御するために、拡張機能をプライベートとして公開します。

展開リング間で変更を移動する

展開リングを介して変更を移動するフローの例を次に示します。

Azure DevOps Developer Tools Build Tasks 拡張機能を使用して、拡張機能をパッケージ化して Marketplace に発行します。

1. Countdown Widget 拡張機能プロジェクトの開発者が、GitHub リポジトリに変更をコミットします。
2. コミットによって継続的インテグレーション ビルドがトリガーされます。
3. 新しいビルドによって継続的配置トリガーがトリガーされ、Canaries 環境のデプロイが自動的に開始されます。
4. Canaries デプロイでは、プライベート拡張機能が Marketplace に公開され、定義済みの組織と共有されます。 カナリアだけが変更の影響を受ける。
5. Canaries デプロイは、早期導入環境のデプロイをトリガーします。 デプロイ前の承認ゲートでは、承認されたユーザーのいずれかがリリースを承認する必要があります。
6. 早期導入者のデプロイでは、プライベート拡張機能がマーケットプレースに発行され、定義済みの組織と共有されます。 カナリアと早期導入者の両方が変更の影響を受ける。
7. 早期導入のデプロイでは、ユーザー環境のデプロイがトリガーされます。 より厳密な展開前承認ゲートでは、承認されたすべてのユーザーがリリースを承認する必要があります。
8. Users デプロイでは、パブリック拡張機能がマーケットプレースに発行されます。 この段階では、組織内に拡張機能をインストールしたすべてのユーザーが変更の影響を受けます。
9. 変更がリング内を移動するにつれて効果が増加することを認識することが重要です。 カナリアと早期導入者に変更を公開すると、運用環境にリリースする前に、変更と修正プログラムの重大なバグを検証する 2 つの機会が与えられます。

問題の監視

監視とアラートは、問題の検出と軽減に役立ちます。 重要なデータの種類 (インフラストラクチャの問題、違反、機能の使用など) を決定します。 ユーザーがアラートを無視し、優先度の高い問題が見つからないのを回避するために、アクション可能なアラートに焦点を当てます。

ヒント

必要に応じて、遠くから見てドリルダウンできる、データの概要ビュー、ビジュアル ダッシュボードから始めます。 ビューの定期的なハウスキーピングを実行し、すべてのノイズを除去します。 ビジュアル ダッシュボードは、多くの通知メールよりも優れたストーリーを示します。多くの場合、メール ルールによってフィルター処理され、忘れ去られています。

Team Project Health やその他の拡張機能を使用して、パイプラインの概要、リードとサイクル時間を構築し、その他の情報を収集します。 サンプル ダッシュボードでは、34 の成功したビルド、21 の成功したリリース、1 つの失敗したリリース、2 つのリリースが進行中であることがわかります。

機能フラグに依存していますか?

いいえ。 場合によっては、リリースの一部として特定の機能を展開する必要がありますが、最初はユーザーに公開されないことがあります。 機能フラグを使用すると、変更に含まれる機能をきめ細かく制御できます。 たとえば、機能について十分な自信がない場合は、機能フラグを使用して 、1 つまたはすべての展開リングで機能を非表示にすることができます 。 カナリア リング内のすべての機能を有効にし、次の図に示すように、早期導入者と運用ユーザーのサブセットを微調整できます。

詳細については、「機能フラグを使用したプログレッシブ実験」を参照してください。

よく寄せられる質問

Q: 次のリングに変更をデプロイできる方法を教えてください。

A: リリースを承認するユーザーに対して一貫したチェックリストが必要です。

Q: 変更を次のリングにプッシュするまで、どのくらいの時間待ちますか?

一定の期間または "クール オフ" 期間はありません。 これは、すべてのリリース検証が正常に完了するまでにかかる時間によって異なります。

Q: 修正プログラムを管理する方法

A: リング 展開モデルを使用すると、他の変更と同様に修正プログラムを処理できます。 問題が早く発生すると、ダウンストリーム リングに影響を与えずに修正プログラムを展開できるようになります。

Q: 共有リリース環境にまたがる変数はどのように処理しますか?

A: 既定のリリース変数とカスタム リリース変数を参照してください。

Q: パイプラインで使用されるシークレットを管理するにはどうすればよいですか?

A: パイプラインで使用される暗号化キーやその他のシークレットを保護するには、Azure Key Vault を参照してください。

関連記事

• 安全なデプロイ プラクティス
• 機能フラグを使用した段階的な実験
• 安全なデプロイ用にリリース パイプラインを構成します。