如何在本地/本地托管 Azure 辅助角色？

Question

一些背景......

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

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

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

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

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

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

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

Answer 1

你认为Azure emulator 会帮助你吗？这些是真正的 Azure 提供程序和模拟器之间的differences。

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

使用PowerShell 配置您的角色等等。 配置您的 Azure 模拟器，例如 this。

Answer 2

说实话，外观方法是最好的方法。

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

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

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

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

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

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