最近，我开始尝试并熟悉一些Azure产品。我制作了一个简单的应用程序，将其与天蓝色功能和天蓝色存储连接起来，以及其他一些产品，例如服务总线。
到目前为止，该应用程序运行良好，我已经尝试了一些很棒的Azure服务。
但现在我不确定如何最好地继续进行，因为到目前为止我的应用程序的开发版本。如果我想制作一个prod版本，我是否必须为开发版本配置一组不同的所有azure资源？
所以基本上，我会有mydevsite.azurewebsites.net和myprodsite.azurewebsites.net。它是否正确？我可以限制mydevsite.azurewebsites.net有一些IP地址限制，因此不公开，但我仍然认为这是一种hacky方式，并且应该有更好的方法。
对于这样的场景，是否有一种常见的方法？
答案 0 :(得分：3)
这是一个广泛的问题，但我可以告诉我之前是如何做到的。
常见的设置是三种环境，Dev，Test和Production。 开发人员主要在开发人员的机器上运行（尽可能多）。我们使用本地IIS安装来运行Web应用程序，使用本地SQL Server作为数据库。 Azure Storage和Cosmos DB也可以在本地进行模拟。某些服务（如搜索示例）无法在本地运行，因此您无论如何都必须在Azure中运行这些服务。
测试和生产基本上是两个相同的资源组，具有相同的资源，只是配置略有不同。所以加倍应用服务计划，SQL数据库等。
根据您的想法，您当然可以跨环境共享资源。但是以某种方式确保他们不会意外地使用其他环境的东西是一个好主意。而明确的不好的一面是，您将生产数据放在与测试数据相同的位置，坦白地说，这些数据不应该在一起。
我知道有些组织在Azure中完全运行Dev环境。可能有几个原因：非常繁重的环境无法真正在开发机器上运行，或者他们也想在开发阶段测试ARM模板部署。
拥有重复的服务允许您使用ARM模板自动部署和更新基础架构，这非常好。
如果您使用标准版或更高版本，您可能会考虑在不同的环境中使用App Service中的部署插槽，但它们实际上并非用于此目的。我们使用它们来减少部署新版本时的应用程序停机时间，如果更新结果不好则使用它们作为后备。因此，部署进入“暂存”部署插槽，该插槽与另一个插槽交换，新版本处于实时状态。然后我们停止部署插槽，这样我们就不会在后台不必要地运行旧版本。
但除此之外，我们还有一个单独的应用服务计划，其中包含单独的Web应用程序和自己的暂存插槽。
部署广告位文档：https://docs.microsoft.com/en-us/azure/app-service/web-sites-staged-publishing