Environments

継続的デリバリープロセスを使用して、生産に新しい価値を迅速かつ安全に提供します。 小さな変更を頻繁に行うことができます。これにより、問題のリスクが軽減されます。

その他の要因は、複数の配信/デプロイ環境の導入など、"運用環境へのデプロイの問題" に影響します。 マルチ環境アプローチを使用すると、より高速で頻度の高いコードをビルド、テスト、リリースして、デプロイを可能な限り簡単にすることができます。 手動によるオーバーヘッドと手動リリースのリスクを取り除き、代わりにさまざまな環境を対象とするマルチステージ プロセスを使用して開発を自動化できます。

一般的なマルチ環境アーキテクチャには、次の 4 つの層が含まれています。

• 発達
• Test
• Staging
• 生産

このアーキテクチャでは、製品は開発 (ソフトウェアへの変更を開発する環境) から運用環境 (ユーザーが直接操作する環境) に移行します。 エンド ツー エンドのビジネス フローを検証するためのユーザー受け入れテスト (UAT) 環境を導入することもできます。

設計に関する考慮事項

Azure ランディング ゾーンと Azure ワークロード開発の両方に次の考慮事項を適用します。

• テスト環境は、プラットフォーム開発者が運用環境にデプロイする前に変更をテストできるため重要です。これにより、運用環境での配信に関連するリスクが軽減されます。
• 環境を可能な限り類似させておくと、テストの最初のフェーズで環境関連のエラーを簡単に見つけることができます。これにより、開発とテストの速度と信頼性が向上します。
• 環境の構成に不一致がある場合は、"構成の誤差" が発生し、データの損失、デプロイの速度低下、および障害が発生する可能性があります。
• Infrastructure as Code (IaC) を採用することで、デプロイを高速化し、環境の一貫性を向上させ、環境間の "構成のずれ" を減らすことができます。
• Canary や Blue-Green デプロイなどの方法を採用することを検討してください。これにより、運用環境の限られたテスト ユーザーのみが新しい機能を使用できるようになり、運用環境にリリースする時間を短縮できます。
• テスト結果のチェックを使用して、開発から運用環境へのコードの移行を制御します。 これらの制御を自動化して、失敗したテストによって変更が自動的に次の環境にデプロイされないようにすることができます。
• コードが運用環境にデプロイされる前に、指定されたユーザーが pull request を確認するようにします。 ブランチ戦略でリポジトリを使用してレビュー プロセスを管理することを検討してください。
• すべての開発者がすべての環境にアクセスできるようにすることで、サイロを回避します。

Workloads

ワークロードの環境を管理する方法については、 エンタープライズ規模の FAQ を参照してください。

Azure ランディングゾーン

Azure ランディング ゾーンのデプロイに複数の環境を採用することは、お客様が新しい Azure Policy の割り当て、Azure RBAC ロールの割り当て、Microsoft Entra グループ メンバーシップ、Azure リソースの作成などの効果と結果をテストする場合に一般的です。

エンタープライズ規模のテスト アプローチ では、次の 2 つの異なる導入方法について説明します。

• カナリア環境と運用環境での管理グループ階層のレプリケーション
• サンドボックス サブスクリプション

フォローするアプローチに関係なく、常に次の操作を行う必要があります。

• テスト用に少なくとも 1 つの環境を採用します。
• 環境を保護するために、テストと運用の目的で個別のサービス プリンシパルを使用します。
• 特定の環境に変更をデプロイする前に、変更を検証および承認するための自動チェックと承認を実装する

次のステップ

• 環境を作成してターゲットにする

• デプロイに環境を使用する (GitHub)