azure - 这是有效且可能的Azure QA环境吗？

Question

我正在尝试为我公司的应用程序套件制定有效的dev/test/QA环境，以迁移到Azure。但是，我对我们的dev/test/qa/etc施加了约束。环境实际上是在内部托管的，并通过构建服务器(例如CC.NET，TeamCity，Jenkins等)进行部署。

在这样的“测试环境”中，我们需要能够触发未发布代码(和数据)的特定快照的部署，以供QA和业务专业人员团队进行技术测试和业务验收测试。显然，所有这些人都不会在Visual Studio中编译并击中F5来进行此测试，因此我们需要一个部署环境。在我们的SDLC中，我们实际上要经历大约4个这样的环境，然后才能进行过渡和生产。简而言之，我们需要一个开销低(自动部署)且易于重现的流程。

在规划此环境时，“如何托管Azure服务”问题显然是困难的部分。因此，让我们看一下Azure的每个部分。斜体选项是我们要使用的选项。

Web角色好吧， IIS可以为我们处理这些(至少足以应付开发/测试情况-除了真正的负载测试，所有这些显然我们必须在Azure中进行，这是美好的)。

工作人员角色看来，这里有两个选择。首先是拥有一个类似于Windows Service的“包装器应用程序”，我们可以使用它来承载我们的工作人员角色要求功能的DLL(毕竟，我们真正的工作人员角色项目不应该仅仅是一个配置文件和调用DLL进行工作的约4行代码)。该选项有效，但是需要一些非常不同的应用程序代码和部署代码管理/维护。 第二个选项是使用Azure Compute Emulator。只要您的辅助角色不需要监视外部端口或任何其他设备，此方法就起作用。在我们的案例中，我们的工作人员角色仅需要监视队列，然后访问各种资源。 的问题在于不同的生成脚本，因为将部署自动执行到Azure仿真器的唯一方法是在托管Azure Emultor的计算机(可能不是您的生成服务器)上运行CSPack和CSRun。因此，您必须执行某种远程脚本来完成此任务。

VM角色 我们并不真正在乎这些，因此我完全忽略了测试的这一方面。

队列在这里，我们有3个选项。首先是使用MSMQ。因为这需要我们没有的完全不同的代码库(或至少围绕该不同代码库的抽象)，所以我不考虑此选项。第二个是将队列保持在Azure中，因为它们是如此之小/便宜。实际上，我们暂时会这样做，直到可以尝试第三个选项为止。 第三个选项是使用Azure存储模拟器。我不确定，但我相信此选项将仅允许在本地计算机上运行的服务访问存储对象。对于队列，我们​​的应用程序代码是实际上“部署”队列的代码，因此只要我们的应用程序代码实际上在承载Azure存储模拟器的服务器上运行，就可以了。

表在这里，我们有3个选项。第一个是我讨厌的，那就是使用数据库并在其中创建一个表来访问这些表。我没有考虑那种选择。第二个是将表保留在Azure中。我不喜欢这样，因为对于可能存储大量数据(每条记录最多1MB)的数据来说，这是来回回事。尽管队列非常轻巧且便宜，但表成本却可以迅速增加。 这使我们使用Azure存储模拟器进入第三个选项。我不确定，但我相信此选项将仅允许在本地计算机上运行的服务访问存储对象。 我仍然不了解模拟器中的所有优点/缺点表。

Blob 在这里，我们实际上有2个选择。首先是一个不好的问题，那就是将它们保留在Azure中。这些文件很可能是很大的文件，所以这是不明智的。 因此，第二个选项再次是使用Azure存储模拟器。我认为这是我们需要做的。

因此，假设我们拥有MVC Apps(Web角色)，WCF Web服务(Web角色)，由队列触发但访问表，Blob和WCF Web服务的队列，表，Blob和Worker角色，这是否看起来像一个托管我们内部质量检查(或类似环境)的合理方法？除了使用远程脚本CSPack和CSRun部署到Azure模拟器的烦恼之外，这一切听起来都可以通过构建服务器自动实现吗？

Answer 1

恕我直言:您遇到了太多麻烦，不必针对Dev＆QA环境部署到Azure。为什么不同时部署和测试部署脚本？使用Xtra-small实例可以降低成本。

存储的模拟一点也不是那么好。有许多细微的差异会使您的测试不可靠。您也没有测试负载平衡-这会发现任何未计划的 session 状态问题