这是一个有效且可能的Azure QA环境吗？

Question

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

在这样的"测试环境"中,我们需要能够为QA和业务专业人员团队触发未发布代码(和数据)的特定快照的部署,以测试技术测试和业务验收测试.显然,所有这些人都不会编译并在Visual Studio中使用F5来进行此测试,因此我们需要一个可以部署的环境.在我们的SDLC中,在进行升级和生产之前,我们实际上经历了~4个这样的环境.简而言之,我们需要一个低开销(自动部署)和易于重现的流程.

在规划这个环境时,"如何托管Azure服务"这个问题显然很难.让我们来看看Azure的每个部分.斜体选项是我们想要的选择.

• Web角色嗯,IIS可以或多或少地为我们处理这些(至少足以用于开发/测试情况 - 除了真正的负载测试,显然我们必须在Azure中做,这很好).
• 工人角色我们在这里有两个选择.第一个是有一个Windows服务的"包装应用程序",我们可以使用它来托管我们的工作者角色调用功能的DLL(毕竟,我们真正的工作者角色项目不应该只是一个配置文件和调用DLL来执行工作的~4行代码.该选项有效,但需要一些非常不同的应用程序代码和部署代码管理/维护.第二个选项是使用Azure计算模拟器.只要您的工作者角色不需要监视外部端口或任何东西,这就可以工作.在我们的例子中,我们的工作者角色只需要监视队列,然后访问各种资源.与此问题(S)围绕着构建别共脚本,因为只有这样,才能自动部署到Azure的仿真器是运行CSPack和CSRun托管在Azure Emultor,这可能不是您的构建服务器的机器上.因此,您必须执行某种远程脚本来完成此任务.
• VM角色 我们并不关心这些,所以我完全忽略了这方面的测试.
• 队列在这里,我们有3个选项.首先是使用MSMQ.因为这需要一个我们没有的完全不同的代码库(或者至少围绕那个不同的代码库进行抽象),我不会考虑这个选项.第二个是将队列保留在Azure中,因为它们非常小/便宜.我们实际上暂时这样做,直到我们可以尝试第三种选择.第三种选择是使用Azure存储模拟器.我不确定,但我相信这个选项只允许在本地计算机上运行的服务访问存储对象.对于队列,我们​​的应用程序代码是实际"部署"队列的代码,因此只要我们的应用程序代码实际在托管Azure存储模拟器的服务器上运行,这应该没问题.
• 表格在这里,我们有3个选项.第一个是我讨厌的,那就是使用数据库并在其中创建一个表来访问这些表.我不是在考虑这个选择.第二个是将表保留在Azure中.我不喜欢这个,因为对于那些可能存储大量数据(每条记录高达1MB)的东西来说,这是很多来回.虽然队列非常轻巧且便宜,但桌面成本可以很快增加.这使我们第三个选择,使用Azure存储模拟器.我不确定,但我相信这个选项只允许在本地计算机上运行的服务访问存储对象.我仍然不理解模拟器中的所有优缺点表.
• Blob在这里,我们有两个选择.第一个是坏的,这是将它们保存在Azure中.这些是最有可能的文件,因此这是不明智的.因此,第二个选项再次是使用Azure存储模拟器.我认为这是我们需要做的.

因此,假设我们有MVC应用程序(Web角色),由队列触发但访问表,blob和WCF Web服务的WCF Web服务(Web角色),队列,表,Blob和工作者角色,这看起来像是合理的方式来托管我们的内部QA(和类似)环境？除了使用远程脚本CSPack和CSRun部署到Azure模拟器的一些烦恼之外,使用构建服务器这一切听起来是否合理自动化？

Answer 1

恕我直言:你正在跳过太多的箍,没有必要部署到Azure for Dev&QA环境..为什么不在同一时间部署和测试你的部署脚本？使用xtra-small实例来降低成本.

存储的仿真根本不是/那么好.有许多细微差别会使您的测试不可靠.您也没有测试负载平衡 - 这会发现任何未计划的会话状态出现问题

Answer 2

关于Azure我最有用的建议之一就是"尽快在Azure上测试".它将帮助您在开发生命周期中尽早解决真实Azure和模拟器之间的差异,并且有很多.

其次,您的替代解决方案听起来像是为了拥有测试环境而做的大量工作.我认为在Azure上托管会更具成本效益.最后,在发布产品之前,您仍需要在Azure上进行测试.