我正在尝试为我公司的应用程序套件制定有效的开发/测试/ QA环境，以便迁移到Azure。但是，我正在强制执行我们的dev / test / qa / etc的约束。环境实际上是在本地托管并通过构建服务器（例如CC.NET，TeamCity，Jenkins等）部署。
在这样的“测试环境”中，我们需要能够为QA和业务专业人员团队触发未发布代码（和数据）的特定快照的部署，以测试技术测试和业务验收测试。显然，所有这些人都不会编译并在Visual Studio中使用F5来进行此测试，因此我们需要一个可以部署的环境。在我们的SDLC中，在进行升级和生产之前，我们实际上经历了~4个这样的环境。简而言之，我们需要一个低开销（自动部署）和易于重现的流程。
在规划此环境时，“如何托管Azure服务”这一问题显然很难。让我们来看看Azure的每个部分。斜体选项是我们想要的选择。
- 网络角色那么， IIS可以或多或少地为我们处理这些 （至少足以用于开发/测试情况 - 所有但真正的负载测试显然我们必须在Azure中做，这很好。）
- 工作者角色我们在这里有两个选择。第一个是有一个Windows服务的“包装应用程序”，我们可以使用它来托管我们的工作者角色调用功能的DLL（毕竟，我们真正的工作者角色项目不应该只是一个配置文件和调用DLL来执行工作的~4行代码。该选项有效，但需要一些非常不同的应用程序代码和部署代码管理/维护。 第二个选项是使用Azure Compute Emulator。只要您的工作者角色不需要监视外部端口或任何东西，这就可以工作。在我们的例子中，我们的工作者角色只需要监视队列，然后访问各种资源。 这个问题围绕着不同的构建脚本，因为自动化部署的唯一方法是Azure模拟器将在托管Azure Emultor的计算机上运行
CSPack和CSRun，这可能不是您的构建服务器。因此，您必须执行某种远程脚本来完成此任务。
- 虚拟机角色 我们并不关心这些 ，所以我完全忽略了这方面的测试。
- 队列在这里，我们有3个选项。首先是使用MSMQ。因为这需要一个我们没有的完全不同的代码库（或者至少是围绕不同代码库的抽象），我不会考虑这个选项。第二个是将队列保留在Azure中，因为它们非常小/便宜。我们实际上暂时这样做，直到我们可以尝试第三种选择。 第三个选项是使用Azure存储模拟器。我不确定，但我相信此选项只允许在本地计算机上运行的服务访问存储对象 。对于队列，我们的应用程序代码是实际“部署”队列的代码，因此只要我们的应用程序代码实际在托管Azure存储模拟器的服务器上运行，它就应该没问题。
- 表格在这里，我们有3个选项。第一个是我讨厌的，那就是使用数据库并在其中创建一个表来访问这些表。我不是在考虑这个选择。第二个是将表保留在Azure中。我不喜欢这个，因为对于那些可能存储大量数据（每条记录高达1MB）的东西来说，这是很多来回。虽然队列非常轻巧且便宜，但桌面成本可以很快增加。 这使我们使用Azure存储模拟器进入第三个选项。我不确定，但我相信这个选项只允许在本地计算机上运行的服务访问存储对象。 我仍然不了解模拟器中的所有优缺点表。
- Blob 在这里，我们有2个选项。第一个是坏的，这是将它们保存在Azure中。这些是最有可能的文件，因此这是不明智的。 所以第二个选项再一次是使用Azure存储模拟器。我认为这就是我们需要做的事情。
因此，我们拥有MVC应用程序（Web角色），由队列触发但访问表，blob和WCF Web服务的WCF Web服务（Web角色），队列，表，Blob和工作者角色，这样做似乎是一种合理的方式来托管我们的内部QA（和类似）环境？除了使用远程脚本CSPack和CSRun部署到Azure模拟器的一些烦恼之外，使用构建服务器这一切听起来是否合理自动化？
2 个答案:
答案 0 :(得分：10)
恕我直言：你正在跳过太多的箍，没有必要部署到Azure for Dev＆amp; QA环境..为什么不在同一时间部署和测试您的部署脚本？使用xtra-small实例来降低成本。
存储的仿真根本不是/那么好。有许多细微差别会使您的测试不可靠。你也没有测试负载平衡 - 会发现任何未计划的会话状态
的问题
答案 1 :(得分：7)
我获得的Azure最有用的建议之一就是“尽快在Azure上测试”。它将帮助您在开发生命周期中尽早解决真实Azure和模拟器之间的差异，并且有很多。
其次，您的替代解决方案听起来像只有测试环境的许多工作。我认为在Azure上托管会更具成本效益。最后，在发布产品之前，您仍需要在Azure上进行测试。