Azure Deployment Environmentsは2027年2月22日に廃止されます。 今すぐ退職プランの開発を始め、既存の環境を在庫管理し、代替ワークフローを検証し、退職前に移行とクリーンアップを完了しましょう。
Note
2027年2月22日までにAzureデプロイメント環境のワークフローをMicrosoftサービス、Azureサービス、またはパートナーソリューションに移行してください。 Azure Deployment Environmentsはこの日に廃止されます。
アクションへの誘い
- 今すぐ退職計画の策定を始めましょう。 ADE 環境、定義、カタログ、環境タイプ、プロジェクト、開発センター、デプロイ用サブスクリプション、ID、ロールの割り当てを棚卸しします。
- 各ADEシナリオに対して、ガバナンス、アクセス制御、インフラストラクチャ・アズ・コード、ネットワーク、コスト管理、ライフサイクル、開発者セルフサービス要件を含む代替アプローチを選択し検証します。
- ユーザーと自動化を2027年2月22日までに代替ワークフローに移行してください。
- コスト削減と正式なADEからのオフボード化のために、未使用環境や顧客所有のAzureリソースを削除しましょう。
Important
Microsoft Dev Boxは別途2028年9月18日の廃止日を設定しています。 Microsoft Dev Box への依存関係が残っていないことを確認するまで、共有の Dev Center リソースを削除しないでください。
切り替えガイダンスの概要
Microsoft、Azure、パートナーのソリューションをレビューし、開発環境のシナリオをサポートしましょう。 ADEはすべてのワークロードに対して一対一の代替手段を提供しているわけではないので、各選択肢をあなたの技術的・組織的要件と照らして評価してください。
Microsoft ソリューション
これらのMicrosoftおよびAzureアプローチは、Azureデプロイメント環境の代替と考えてください。
Azure Resource Manager and Bicep
Azure Resource ManagerのテンプレートやBicepを使った直接インフラストラクチャ・アズ・コード展開を検討してみてください。チームがサブスクリプション、リソースグループ、アイデンティティ、ポリシー、デプロイオーケストレーション、ライフサイクルコントロールを既存のプラットフォームエンジニアリングプロセスを通じて管理できる場合です。
Azure 検証済みモジュール
チームがAzureリソースの標準化された管理されたビルディングブロックを必要とする場合は、再利用可能なAzure認証モジュールを検討してください。 移行前にモジュールのカバレッジ、バージョン管理、ポリシー統合、所有権を検証してください。
Azure DevOps と GitHub ワークフロー
環境プロビジョニングをリポジトリやパイプラインに統合できる場合、CI/CDワークフローを考慮してください。 DED固有のコマンド、SDK連携、Dev Centerプラットフォームを対象とした azd 設定を再構築してください。
Azure パートナー ソリューション
私たちが特定したサードパーティのソリューションのいずれも、BicepやARMのライフサイクルを直接サポートしていません。 AzureでBicepやARMを直接デプロイしてください。
ソリューションを選択する前に、代表者がポリシー、アイデンティティ、ログ、故障回復、コスト管理シナリオを作成、更新、削除するテストを行います。
Azureデプロイメント環境の廃止に関するよくある質問
Azureデプロイメント環境はいつ廃止されるのでしょうか?
Azure Deployment Environmentsは2027年2月22日に廃止されます。 この日までに生産移行を完了してください。
退職日には何が起こるのですか?
ADEの作成、展開、再展開、その他の書き込み操作はブロックされることが期待されます。 インベントリ、読み取り、ログ記録、および削除の各操作は、期限付きのクリーンアップ期間中も引き続き利用可能とする予定です。
ADEの退職はMicrosoft Dev Boxも引退するのでしょうか?
No. Microsoft Dev Boxは別途2028年9月18日の廃止日を設定しています。 Dev Boxの定義、画像、プール、スケジュール、ネットワーク接続、ユーザー操作はADEの廃止日以降も継続されます。
共有の開発センターやプロジェクトを削除できますか?
Dev Boxの依存関係が残っていないことを確認してからです。 プロジェクトをリンクされた開発者センターにマッピングし、共有親リソースを削除する前にDev Boxのプールや他のDev Boxリソースをチェックしてください。
影響を受けるリソースはどのように特定すればよいですか?
Service RetirementワークブックとAzure Resource Graphを使って、アクセス可能なサブスクリプション内のADEホストおよびコントロールプレーンリソースを特定してください。 ADE環境インスタンスにはAzure Resource ManagerのリソースIDがないため、開発者ポータル、Azure CLI、ADEデータプレーンAPI、既存の運用テレメトリを通じて環境を個別に導入します。
環境をどうやって移行すればいいですか?
テンプレート、カタログのソース参照、パラメータ、設定を保存します。 ターゲットプラットフォームを選びましょう。 プロビジョニングの自動化を再構築しましょう。 ガバナンスとライフサイクルの管理を検証すること。 代表的な展開や復旧手順をテストしてください。 退職前にユーザーと自動化を移行しましょう。
ADE環境はどうやって削除すればいいですか?
- 開発者ポータル内の各環境を開き、その詳細とデプロイメントリソースグループを確認してください。
- 環境を削除し、削除範囲を確認してください。
- Azureポータルのデプロイメントリソースグループを開き、どのリソースが削除されたか確認してください。
- 顧客所有のリソースは、もはや必要とされていないものを削除してください。
- 依存関係がなくなった後は、ADE専用の環境タイプ、定義、カタログ、アイデンティティ、役割割り当て、そして昇格された展開権限を削除してください。
環境を削除すればすべての充電が止まるのでしょうか?
必ずしもその必要はありません。 ADEメタデータを削除しても、環境が展開したすべてのAzureリソースが削除されるわけではありません。 管理型デプロイメントリソースグループ外のリソースは、削除するまで稼働し続け、請求が発生することがあります。 Azure Cost Managementのデータを確認し、予定された請求が停止したか確認してください。
助けはどこで得られますか?
Microsoft Q&Aをご利用ください。コミュニティのガイダンスとして。 Azure サポートプランをお持ちで技術支援が必要な場合は、Azure サポートリクエストを作成してください。