0

开发时,我的团队显然使用development作为我们的环境。Rails应用程序,持续集成/部署环境

当我们运行自动测试时,我们使用testing

我们还有stagingproduction环境,分别用于我们的测试人员检查功能和最终“现场”产品。

我们正在尝试设置内部CI服务器来运行我们的自动化测试,并最终帮助自动部署。

由于CI服务器确实在运行自动化测试,有人认为它应该在testing环境中运行。但是,为了使CI服务器真正有用,我的想法是,它需要在production模式下运行,尽可能接近实际的production环境的镜像(显然不涉及生产数据库)。

是否有一个可以接受的环境,应该在CI服务器下执行? production环境(不同的DB)似乎是唯一符合逻辑的答案给我,但我可能失去了一些东西......

回答

1

PROD环境中运行任何测试,如你所说

似乎是唯一符合逻辑的答案

但并不完全正确。您的测试可能会严重损害实际环境/应用程序,并面临恢复选项的风险。在所有测试的阴暗面都显示/发现你的软件不仅有小错误,而且它的工作并不像预期的那样。 我能想到的,至少这些“为什么不试生产”方面的考虑:

  • 时,产品一经推出,客户依赖它。期待您的软件正在运行()已经过测试)。你的生活环境应该完成它的工作,而不是被加载测试。如果产品出现故障(或未执行),必须派遣技术团队来弥补损坏,修复缺陷并使其无障碍运行。现在这不仅影响了产品成本,而且主要延迟了项目期限。这将对供应商的利润和接下来的几个项目产生递归效应。

  • 生产或开发团队在完成产品开发时,必须在为其测试环境加载新开发的产品之前为测试团队生成此测试环境。

对我来说,不管你

也有临时和生产环境

有必要相应地使用测试之一。进一步更多测试环境应该(配置)尽可能接近生产。另一个人可能试图测试,而另一个人打破他一直在测试的东西。除了两者分开之外,他们无法做适当的测试。

只是作为完整答案,您的STAGE环境可以根据公司的不同而发挥不同的作用。 一个是它可以是QA/STAGE环境,它具有用于QA和系统测试(在大量更新/更改或升级即将投入生产时测试系统)的生产副本。

UPDATE:

这是我的观点了。 QA环境应该是PROD的镜像。关于将文件缓存/预加载到分段/生产的问题的可能解决方案是创建预/后步骤 .bat(让我们假设)文件。

在我们当前的测试项目中,我们使用这种方法。在的前置步骤我们设置了测试执行所需的文件(例如从先前的运行中删除文件并下载最新的副本/工件)。在后续步骤我们设置了需要的报告文件。好处是您的文件将在每次执行之前收集并同步。

关于

不是在我的情况相同的物理硬件

我们支持专用的远程测试服务器。优点很明显,只有你需要考虑的是它需要维护(管理)。

+0

我不打算让CI在与生产相同的物理硬件上运行,而只是在相同的环境下(相同的DB版本,操作系统版本等)。我衷心地同意将所有内容扔到prod服务器上是一个坏主意。我遇到了Rails代码在开发/测试中效果很好的问题,但是在分段/生产中完全相同的代码失败,因为Rails在这些环境中以缓存/预加载文件的方式做了不同的事情。我认为最好的解决方案是尽可能模仿生产环境,而不是在同一个物理硬件上。 – 2014-10-09 17:26:11