Microsoft Fabric は、顧客エクスペリエンスとサービス品質の問題に対処するために、サービスとオンデマンドの対象修正プログラムに対して毎週の新機能と機能更新プログラムをリリースします。 このアプローチは、速度と安全性のバランスを取るために意図されています。 次の図に示すように、Microsoft Fabric のコード変更は、外部のお客様に広くデプロイされる前にいくつかの検証ステージを通過します。
Microsoft Fabric コード ベースに対するすべての変更は、一般的なシナリオを検証し、対話によって期待される結果が得られるようにする、自動化されたコンポーネントとエンド ツー エンドのテストを通過します。 さらに、Microsoft Fabric では、主要な開発ブランチ上の継続的インテグレーション/継続的配置 (CI/CD) パイプラインを使用して、変更ごとに識別するコストが高いその他の問題を検出します。 CI/CD プロセスは、完全なクラスター ビルド アウトと、変更がリリース プロセスの次のステージに入る前に合格する必要があるさまざまな合成テストをトリガーします。 承認された CI/CD ビルドは、毎週の機能更新プログラムに含まれる前に、より自動化された手動検証のために内部テスト環境にデプロイされます。 このプロセスは、開発者が完了してから 1 ~ 7 日以内に、変更が候補リリースに組み込まれることを意味します。
その後、毎週の機能更新プログラムは、Microsoft Fabric の安全なデプロイ プロセスのさまざまな公式展開リングを通過します。 更新された製品ビルドは、まず、Microsoft Fabric チームのコンテンツをホストする内部クラスターに適用され、その後、Microsoft 全体のすべての従業員が使用する内部クラスターが適用されます。 変更は、これらの各環境で 1 週間待機してから、最後の手順である運用環境のデプロイに移行します。 ここでは、デプロイ チームは段階的なロールアウト プロセスを採用しています。このプロセスでは、リージョンごとに新しいビルドを選択的に適用し、広範なアプリケーションの前に特定のリージョンで検証できるようにします。
展開規模の拡大
このデプロイ モデルをスケーリングして、指数関数的なサービスの増加に対応するには、以下に示すようにいくつかの方法で行います。
包括的な依存関係のレビュー - Microsoft Fabric は、多くのアップストリーム依存関係と非依存関係のハードウェア容量要件を備えた複雑なサービスです。 デプロイ チームは、ターゲット デプロイ リージョン内のすべての依存リソースとサービスの可用性と必要な容量を確保します。 使用量モデルは、予想される顧客の需要に基づいてプロジェクトの容量のニーズをモデル化します。
Automation - Microsoft Fabric のデプロイは基本的にゼロタッチであり、デプロイ チームによる操作はほとんど必要ありません。 事前構築済みのロールアウト仕様は、複数のデプロイ シナリオに対して存在します。 デプロイの構成はビルド時に検証され、ライブ 展開のロールアウト中に予期しないエラーが発生しないようにします。
クラスターの正常性チェック - Microsoft Fabric デプロイ インフラストラクチャは、アップグレードの前後およびアップグレード後に内部サービス正常性モデルをチェックして、予期しない動作と潜在的な回帰を特定します。 可能な場合、デプロイ ツールは、発生した問題の自動軽減を試みます。
インシデント対応プロセス - 展開の問題は、他のライブ サイト インシデントと同様に処理されます。 エンジニアは、直ちに軽減策に重点を置いて問題を分析し、関連する手動または自動化されたプロセスの変更をフォローアップして、将来の再発を防ぎます。
機能管理と露出制御の - Microsoft Fabric は、新しい機能を顧客に選択的に公開するための包括的なフレームワークを適用します。 機能公開はデプロイの周期に依存せず、関連するすべての品質バーを通過するまで、新しいシナリオ コードのコードを無効な状態でデプロイできます。 さらに、新しい機能は、グローバルに有効にする前の追加の検証手順として、Microsoft Fabric の母集団全体のサブセットに公開できます。 問題が検出された場合、Microsoft Fabric 機能管理サービスは、時間のかかるデプロイロールバック操作を待たずに、問題のある機能を数秒で無効にする機能を提供します。
関連コンテンツ
- Microsoft Fabric の概念とライセンス
- Microsoft Fabric の機能パリティ