16

我工作的公司似乎一直在与客户的服务器环境作斗争。

具体来说，我们几乎总是会遇到测试服务器和生产服务器的问题，而且它们似乎总是配置不同。当我们测试我们开发的应用程序时，测试服务器以一种方式运行，因此我们调整和配置我们的应用程序以适应该特定行为。但是当我们在生产服务器上安装相同的应用程序时，我们会观察到另一种与测试服务器不一致的行为，从而使我们的调整和配置变得毫无用处。最令人沮丧的是，这种情况一直在发生，而且似乎没有人知道该怎么做。

当然，我们对为什么会发生这种情况有一个大致的了解。每个克隆的环境开始时都是一样的，并且在前几天的工作方式相同，但迟早有人只在一个服务器环境中重新配置某些东西（无论是数据库更新、组件库更新、Web 文件更新，或其他配置），从而导致差异。随着时间的推移，越来越多的差异越来越大。但问题是：我们能做些什么呢？

我试过在网上搜索，但找不到任何关于该做什么的好答案。我也试图自己找出一些解决方案，但我的大多数想法似乎在某种程度上存在问题。新的套路，无论多么严格，都可以规避。定期克隆生产服务器以创建测试服务器是一个乏味且通常非常缓慢的过程。自动复制并不总是可靠的，甚至是不可能的。那么我们究竟应该如何解决这个问题呢？我们如何保证测试时的体验与上线时的体验相匹配？

我想其他人也有这个问题。还是他们？也许只是我的特定公司不称职？你们有没有遇到过这个问题？如果是这样，你做了什么？

真挚地，

Linus，瑞典系统开发人员

4

5 回答 5

6

您需要开始跟踪您对测试环境所做的每一次更改，并提供一种将其传播到生产环境的方法。

对于代码，这意味着版本控制系统，例如 CVS、Subversion 或 GIT。

对于数据库，它意味着更新生产数据库的结构比较工具或部署脚本。

对于配置，两个系统应该完全相同，任何“调整”或更改都需要首先应用于测试服务器，然后在部署期间应用于生产服务器。

除非您有一个有效的流程，否则您将继续遇到问题。

于 2009-03-12T17:40:35.397 回答
0

当然，我们对为什么会发生这种情况有一个大致的了解。每个克隆的环境开始时都是一样的，并且在前几天的工作方式相同，但迟早有人会在其中一个服务器环境中重新配置某些东西

我认为你很慷慨，或者你很幸运。通常情况下，需要外包开发工作的商店并不真正了解开发过程。如果他们为您提供了一个测试环境，您将获得的是他们上次服务器刷新之前的生产系统。

于 2009-03-13T15:10:24.283 回答
0

为了使 MySQL 数据库保持同步，我刚刚遇到了这个工具：

http://schemasync.org/

我还没有真正使用它，所以我不能说它是否有好处，但我们需要一些方法来控制测试和产品之间的模式漂移，所以我们要试一试。

于 2011-06-01T23:05:53.217 回答
0

您需要确保以一致的方式对环境进行任何更改。

我会考虑从新图像开始并执行严格的修改日志策略，或者使用 Capistrano 之类的东西在所有机器上执行远程命令并将代码同时部署到所有机器上。

理想情况下，所有需求都应该检查到您的版本控制系统中（按照 Rails 如何让您将 gem 存储在 /vendor 目录中并优先在运行时加载它们的方式），以及一个描述如何设置环境的自述文件（所需的库等）。任何对环境进行更改的人都需要严格更新自述文件。

于 2009-03-12T17:37:42.020 回答
0

你的问题很正常。我知道至少有两种策略效果很好：

如果你在 linux 上分发，你可以从你的开发过程中构建 rpms/debs 并使用包管理功能。我知道很多项目在内部项目中都取得了巨大的成功。

另一种选择是将整个环境打包为某种 shell 脚本。这个 shell 脚本可以/应该使用所有设置来配置完整的环境。通常这个脚本是由开发人员维护的，这个脚本会覆盖手动进行的任何修改。像这样的脚本通常由开发人员维护，处于版本控制之下，并作为完整的发行版发送到部署。为此，我们使用 cygwin。通常，脚本会读取某种可能由操作管理的配置。我的脚本实际上是从头开始设置整个系统，就好像安装在一台完全空白的、新安装的机器上一样。

这两种策略最好都应该包括从构建脚本/构建系统一直自动生成这些工件。这个过程运行得越顺畅，对所有相关方都越好。

于 2009-03-12T17:41:25.363 回答