保持测试和生产服务器环境的干净、同步和一致性

Question

似乎我工作的公司总是在与客户的服务器环境搏斗。

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

当然，我们对为什么会出现这种情况有一个大致的想法。每个克隆环境都是相同的，并在前几天内按相同方式工作，但早晚有人将某些内容重新配置到其中一个服务器环境中（无论是数据库更新、组件库更新、Web文件更新或其他配置），从而引起差异。随着时间的推移，差异越来越多。但问题是：我们该怎么办呢？

我尝试搜索互联网，但找不到好的解决方案。我也试图自己想出一些解决方案，但是我的大多数想法似乎在某些方面都有问题。无论多么严格的新例程都可以被规避。定期克隆生产服务器以创建测试服务器是一个繁琐而常常非常缓慢的过程。自动复制并不总是可靠的，甚至有时根本不可能。那么我们应该如何解决这个问题呢？我们如何保证测试时的体验与实际上线时的体验相匹配呢？

我想象其他人也有这个问题。或者他们没有？也许只是我所在公司的无能？你们中有没有遇到过这种问题？如果有，你们是怎么解决的？

诚挚地,

瑞典系统开发者Linus

- Linus

---

Linus，这个问题特别是指将代码交付给客户的环境，对吧？你在这些环境中实际上能够施加多少控制？ - Jeff Atwood

另外，您能列出您支持客户的环境吗？Windows？Linux？Mac？目前您有哪些要求？ - Jeff Atwood

Answer 1

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

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

对于数据库来说，这意味着使用结构比较工具或部署脚本来更新生产数据库。

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

除非你有一个可行的流程，否则你将继续遇到问题。

- jonstjohn

---

对于配置管理，如果你感到非常有雄心壮志，可以考虑使用cfengine或puppet来使用声明性语言定义系统配置（已安装的软件包、配置文件内容等）。 - Peter Cordes

Answer 2

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

http://schemasync.org/

我实际上还没有使用过它，所以无法评价它是否好用，但我们需要一些方法来控制测试和生产环境之间的模式漂移，因此我们将尝试使用它。

- user41871

Answer 3

您需要确保环境的任何更改都以一致的方式完成。

我建议要么从新的镜像开始并强制执行严格的修改日志策略，要么使用像Capistrano这样的工具在所有机器上同时执行远程命令并部署代码。

理想情况下，所有要求都应该被检入到您的版本控制系统中（类似于Rails让您将gems存储在/vendor目录中，并优先在运行时加载），同时附带一个readme文件，描述如何设置环境（必需库等）。任何对环境进行更改的人都需要严格更新readme文件。

- Jarin Udom

Answer 4

你的问题很普遍。我知道至少有两种策略可以相当好地解决：

如果你在Linux上分发，你可以从开发过程中构建rpm/deb并使用软件包管理功能。我知道许多项目都在内部项目中取得了巨大成功。

另一种选择是将整个环境打包为某种shell脚本。这个shell脚本可以/应该配置完整的环境和所有设置。通常，这个脚本由开发人员维护，并覆盖任何手动进行的修改。像这样的脚本通常由开发人员维护，保存在版本控制下，并作为完整的分发发送到部署。我们使用cygwin来实现这一点。通常，脚本会读取某种由运营管理的配置。我曾经编写过的脚本实际上可以从头开始设置整个系统，就像在全新安装的机器上安装一样。

这两种策略都应该包括从你的构建脚本/构建系统自动生产这些工件。这个过程越顺畅，对所有相关方面都越好。

- krosenvold

Answer 5

当然，我们大致知道为什么会发生这种情况。每个克隆环境都是相同的，并且在最初的几天内工作方式也相同，但迟早有人会在其中一个服务器环境中重新配置某些内容。

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

- Joel Coehoorn