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 回答