Azure CloudServices：ステージングスロットと本番スロットだけではありませんか？
私たちはAzure Cloud Servicesを使用しており、デプロイが次のように流れるワークフローが必要です
Cloud Service #1: testing/QA => staging => production
現在、Azure Cloud Servicesには、デプロイメントを交換できるステージング環境と本番環境しかありません。上記のように、人々はどのように従来の3段階のアプローチに対応していますか？
現在、次のことを行っています
Cloud Service #1: testing/QA => Cloud Service #2: staging => production
ただし、クラウドサービスA =>クラウドサービスBからの移行は本質的に完全な再デプロイであり、単にIPを切り替えるか、ロードバランサーの背後でスワップするだけなので、これは苦痛で扱いにくく感じます。
Azure Webアプリとしてホストされる多くのサービスを開発しています。一部のサービスには、テスト、ステージング、本番用のWebアプリがあります。これらは異なるウェブアプリです。さらに、これらのそれぞれには、ダウンタイムがないか、最小限の展開で展開するためのプレビュースロットと本番スロットがあります。これに加えて、要約すると、トラフィックマネージャーの背後にプライマリインスタンスとフェイルオーバーインスタンスがあります。 1つの論理サービスは、最大12のWebアプリを持つことができます。これはすべて、チームシティーからトリガーされたgitを介したデプロイメントで合理化されています。本番環境に移行する前に、テストとステージングにコミットをデプロイする必要がある明確な階層が適用されています。
Webアプリは1つでも複数でも同じ価格なので、これらすべてが可能です。 Webアプリではなくクラウドサービスを使用しているようですが、別のサービスの場合も同様です。ステージングにはスロット機能を使用しません。