我工作的公司似乎总是在客户的服务器环境中苦苦挣扎。
具体来说,我们几乎总是遇到测试服务器和生产服务器的问题,以及它们似乎总是配置不同的事实。当我们测试我们开发的应用程序时,测试服务器以一种方式运行,因此我们调整和配置我们的应用程序以适应该特定行为。但是当我们在生产服务器上安装相同的应用程序时,我们会发现另一种与测试服务器不一致的行为,从而导致我们的调整和配置无用。最令人沮丧的是,这种情况一直在发生,似乎没有人知道应该怎么做。
当然,我们对这种情况发生的原因有一个大概的了解。每个克隆环境都是以相同的方式开始,并且在前几天工作相同,但迟早有人只在一个服务器环境中重新配置某些东西(无论是数据库更新,组件库更新,Web文件更新,或其他配置),从而导致差异。随着时间的推移,越来越多的差异逐渐增大。但问题是:我们能做些什么呢?
我尝试过在网上搜索,但找不到任何有关该怎么做的好答案。我也试图自己找出一些解决方案,但我的大部分想法在某些方面似乎都有问题。无论多么严谨,都可以规避新的惯例。定期克隆生产服务器以创建测试服务器是一个繁琐且通常非常缓慢的过程。自动复制并不总是可靠的甚至是可能的。那么我们应该对这个问题做些什么呢?我们如何保证测试时的体验与上线时的体验相符?
我想其他人也有这个问题。或者他们呢?也许只是我的特定公司不称职?有没有人遇到过这个问题?如果是这样,你对此做了什么?
此致
Linus,瑞典系统开发人员
答案 0 :(得分:6)
您需要开始跟踪您对测试环境所做的每一项更改,并提供将其传播到生产环境的方法。
对于代码,这意味着版本系统,如CVS,Subversion或GIT。
对于数据库,它表示结构比较工具或部署更新生产数据库的脚本。
对于配置,两个系统应该完全相同,并且任何“调整”或更改需要首先应用于测试服务器,然后在部署期间应用于生产服务器。
在您的流程有效之前,您将继续遇到问题。
答案 1 :(得分:0)
您需要确保以一致的方式对环境进行任何更改。
我要么考虑从新图像开始并强制执行严格的修改日志策略,要么使用像Capistrano这样的东西来执行远程命令并同时将代码部署到所有机器。
理想情况下,所有要求都应该检查到你的版本控制系统(沿着Rails如何让你在/ vendor目录中存储gems并优先在运行时加载那些),以及一个描述如何设置的自述文件环境(必需的库等)。任何对环境进行更改的人都需要严格更新自述文件。
答案 2 :(得分:0)
你的问题很正常。我知道至少有两种策略可以很好地运作:
如果您在Linux上发布,则可以从开发过程构建rpms / debs并使用包管理功能。我知道很多项目在内部项目上取得了巨大成功。
另一种方法是将整个环境打包为某种shell脚本。此shell脚本可以/应该使用所有设置配置完整环境。通常,此脚本由develeopment维护,此脚本将覆盖已手动进行的任何修改。像这样的脚本通常由开发维护,保持在版本控制之下并作为完整分发发送到部署。我们使用cygwin。通常,脚本会读取某些可能由操作管理的配置。我已经有了从头开始实际设置整个系统的脚本,就好像安装在一个完全空白的新安装的机器上一样。
这两种策略最好应该包括从构建脚本/构建系统中自动生成这些工件。这个过程越顺畅,对所有参与方都越好。
答案 3 :(得分:0)
当然,我们对这种情况发生的原因有一个大概的了解。每个克隆环境的开始都是相同的,并且在前几天工作相同,但迟早有人只在一个服务器环境中重新配置某些东西
我觉得你很慷慨,或者你很幸运。经常需要外包开发工作的商店并不真正理解开发过程。如果他们为您提供了一个测试环境,那么您将从最后一次服务器更新之前获得他们的生产系统。
答案 4 :(得分:0)
为了使MySQL数据库保持同步,我刚刚遇到了这个工具:
我还没有真正使用它,所以我不能说它是否有用,但是我们需要一些方法来控制测试和产品之间的模式漂移,所以我们要给它一个镜头。