6

一些背景......

我们是第一次涉足 Azure,并且正在尝试一步一步来。目前,我们的第一个应用程序将成为监控队列以处理请求(例如发送电子邮件或执行一些屏幕抓取)的工作角色,我们只需从我们的本地 MVC 应用程序和 WCF 服务插入队列。我们稍后会将 MVC 应用程序和 WCF 服务移至 Azure。

我们的开发工作流程基本上是这样的(以不重要的方式进行了一些修改):

  1. 在本地和一些共享服务器上开发。检查源代码控制。
  2. 每 15 分钟,构建服务器构建并部署到“开发”环境(兼作 CI 并覆盖以防我们需要访问本地以外的“开发”环境)
  3. 技术测试人员手动触发构建服务器以将最后成功的“Dev”构建部署到测试环境(或者,之前部署的测试构建,包括/排除数据库)。
  4. 技术测试人员和业务测试人员手动触发构建服务器以将最后成功的“测试”构建(或者,之前部署的测试构建,包括/不包括数据库)部署到 QA 环境。
  5. 在某个时候,我们合并了 QA 批准部署的变更集。
  6. 后来我们的生产构建服务器将此版本部署到暂存,然后再部署到我们的生产环境(我们在并行/独立环境中托管它 N 次)。

如您所知,我们有许多内部托管的应用程序版本,供内部支持人员在投入生产之前进行打击。我希望这些对 Azure 的依赖程度相当低。我不需要完成服务器依赖,所以我们将继续使用 Azure 队列,也许还有其他一些机制,因为它们易于继续使用,但我们不希望我们的构建服务器必须部署到 Azure对于这些环境中的每一个(或者为所有托管付费)。

那么,我们如何才能以实际测试部署到 Azure 的代码的方式合理地在本地托管我们的 Worker 角色呢?

建议的一种选择是,我们将工作者角色创建为包装器/外观,并在类库中完成所有实际工作,这是我们的计划。但是,允许我们“托管”它的后续措施是创建第二个包装器/外观应用程序,它执行与工作者角色相同的工作,只是以我们可以将其作为计划任务或窗口运行的方式服务器。归根结底,我不喜欢这个选项,因为整个项目在进入暂存阶段之前从未进行过测试。

是否有可能在我们创建第二个包装器/外观应用程序时做类似的事情,而不是调用它实际引用的类库并Run()在工作角色中调用函数?

4

2 回答 2

5

你认为Azure 模拟器可能对你有帮助吗?这些是真正的 Azure 提供程序和模拟器之间的区别。

为您的工人角色设置一个门面似乎是合理的。并使用适配器将任何可能的云(或其他托管)技术适应该外观?只是想提出一些想法。我之前实际上使用过这种方法,但这是一个“个人”项目。

使用PowerShell来配置你的角色等等。像这样配置你的 Azure 模拟器。

于 2011-08-18T17:16:18.440 回答
2

老实说,外观方法是最好的方法。

当您的部署最终依赖于支持的基础架构时,在部署到相同或可比较的基础架构之前,要进行全面测试会异常困难。Azure Worker Role 肯定就是这种情况。

通过将应用程序的功能方面与基础设施接触点分离,您可以花精力确保代码按应有的方式运行,证明外观按应有的方式运行,然后对最终组合进行置信度测试。

除非您的测试环境与您的生产环境相同,否则总有一些妥协因素会影响这种效果。

这就是 Azure 暂存部署的用途;切换到生产之前的最后一级置信度测试。

您可以创建一个超小型部署,纯粹用于您的后期测试阶段。您为部署角色的时间付费,因此如果您在测试完成后删除部署,则可以最大限度地降低成本。

最后,外观模式是一个示例,可测试性设计。考虑您的代码以最大限度地提高部署前可以测试的数量,并最大限度地降低测试后期阶段的风险。

于 2011-08-18T18:06:52.857 回答