一些背景......
我们第一次冒险进入Azure,并试图按照婴儿步骤进行操作。目前,我们的第一个应用程序将成为工作者角色,监视队列以处理请求(例如发送电子邮件或执行一些屏幕抓取),我们只需从我们的内部部署MVC应用程序和WCF服务插入队列。我们稍后会将MVC应用程序和WCF服务移至Azure。
我们的开发工作流程基本上是这样的(稍微修改一下):
正如您所知,我们的应用程序有许多内部托管版本供内部支持人员在达到生产之前进行打击。我希望这些对Azure的依赖程度相当低。我不需要完成对服务器的依赖,因此我们将继续使用Azure队列和其他一些机制,因为它们很容易继续使用,但我们不希望我们的构建服务器必须部署到Azure对于这些环境中的每一个(并且支付所有托管费用)。
那么我们如何以实际测试部署到Azure的代码的方式合理地托管我们的工作者角色?
我们建议的一个选项是我们将工作者角色创建为包装器/外观,并在类库中完成所有实际工作,这是我们的计划。但是,允许我们“托管”这一操作的后续操作是创建第二个包装器/外观应用程序,它执行与工作者角色相同的工作,只是以我们可以将其作为计划任务或窗口运行的方式服务器。最终,我不喜欢这个选项,因为整个项目在进入分段之前从未进行过测试。
是否有可能在我们创建第二个包装器/外观应用程序时执行类似操作,而不是调用它实际引用的类库并调用辅助角色中的Run()
函数?
答案 0 :(得分:5)
你认为Azure emulator可能对你有帮助吗?这些是真正的Azure提供程序和模拟器之间的differences。
为你的工人角色设置一个外观似乎是合理的。并使用适配器使任何可能的云(或其他托管)技术适应该外观?只想尝试一些想法。我之前实际上使用过这种方法,但这是一个“个人”项目。
使用PowerShell配置您的角色等等。 配置Azure模拟器,如this。
答案 1 :(得分:2)
诚实地说,门面方法是最好的方法。
当您的部署最终依赖于支持基础架构时,在部署到相同或可比较的基础架构之前完全测试非常困难。 Azure工作者角色确实如此。
通过将应用程序的功能方面与基础架构接触点分离,您可以花费精力确保您的代码按照应有的方式运行,证明 facade 表现得如此,然后自信地测试最终的组合。
除非您的测试环境与您的生产环境相同,否则总会有一些妥协因素。
这就是Azure分段部署的用途;在切换到生产之前的最后一级置信度测试。
您可以创建一个超小型部署,纯粹是为了您以后的测试阶段。您需要支付部署角色的时间,因此如果在测试完成后删除部署,则可以最大限度地降低成本。
最后,立面图案就是一个可测试性设计的例子。考虑您的代码以最大化部署之前可以测试的数量,并在后续测试阶段将风险降至最低。