我正在设置一个网络服务器，我想知道更新其中包含的网站的最佳实践方法是什么。我知道我应该有某种并行运行的“测试”服务器，以便在更改生效之前先尝试更改。那么测试服务器应该如何接近生产环境，是否有任何已知的方法可以在测试完成后轻松地将相同的更改部署到生产环境中？
我真的希望有一种万无一失的方法来测试和应用生产网站的更改，并且非常感谢与此相关的任何建议。
平台：
在 Linux ubuntu 服务器上工作。运行 mediawiki、wordpress 和邮件服务器。我通过 ssh 拥有对盒子的 root 访问权限。Mediawiki 和 Wordpress 都有 PHP 和 MySQL 后端。邮件服务器也使用 MySQL 数据库。
答案1
我们使用一系列虚拟机，每个实时客户端服务器至少有一个虚拟机，这些虚拟机与实时机器保持同步（除了一些被混合的数据，因此我们不会处理个人身份信息或其他敏感信息）。
任何将要对生产机器进行的一系列更改都放在一个补丁中，该补丁由所需的所有文件/脚本和一个适当应用这些文件/脚本的脚本（通常用于类 Unix 环境的 shell 脚本，Windows 下的批处理文件或 vbs 脚本或 powershell 脚本）组成。然后，我们获取相关的 VM，如果 VM 的副本太过时，则从生产副本更新其数据库（记得重新运行相关的 SQL 脚本以擦除或随机化敏感数据），并在这种状态下对其进行快照（virtualbox 和大多数 vmware 产品（包括免费的“vmware server”）以及可能大多数其他虚拟化解决方案都支持快照）。然后，我们通过运行主控制脚本将补丁应用到生产服务器，就像我们对生产服务器所做的那样。如果应用更改时出现错误，则 VM 将回滚到快照（最多需要几十秒），以便可以更新并再次尝试补丁。根据需要重复此操作，直到补丁干净地应用。完成后，会要求一些测试人员全部试一下，以确保新东西可以正常工作，而其他旧东西没有损坏（您花多长时间取决于更改的范围和严重程度以及您的偏执程度）。 如果发现问题，则重复回滚、编辑和重新应用的循环，直到一切正常。 一旦一切正常，假设时间允许，将运行最后一次回滚-修补和测试循环以防万一。 完成所有这些操作后，您希望有一个可以通过运行具有适当参数（即相关密码，因为测试虚拟机上的身份验证凭据应与生产计算机上的身份验证凭据不同）的单个脚本应用于生产环境的补丁，并且您可以非常有信心它将干净地应用并产生预期的效果，而没有（或尽可能少）不必要的效果。
无论你花了多少时间测试更新，在将任何重要内容应用到生产系统之前，务必进行全新的备份，以防万一，并且始终计划至少一点停机时间，在此期间你可以阻止其他用户进入并对更新后的系统进行进一步的偏执测试（如果出现严重问题，则将它们回滚到最新备份 - 如果你的生产环境是虚拟化的，那么快照功能在这里也很有用）。
作为一个一般过程，这可以在任何环境下进行。
答案2
使用 capistrano (capistrano 和 php 指南）
测试环境应该尽可能地模拟生产并且保持独立（因此，没有共享数据等）。
答案3
这实际上取决于您对“实时”的定义。例如，您的意思是一台 100％ 正常运行时间且不会宕机的服务器，还是仅仅是关于更新网站的一般问题。
您可以做的最简单的事情就是启用 FTP 访问您的盒子/帐户/存储，如果您只进行了不会破坏其他任何内容的微小更改，则只需在网站上线时覆盖文件，然后下次有人刷新页面时，它就会加载新文件。
但是如果你要进行大的改动而导致其他项目被破坏的话，你（在我看来）有以下几种选择：
- 执行上述操作，逐页上传，并希望没有人注意到/您做得足够快。
- 将站点脱机，进行更改并重新上线。
- 按照我的做法做（尽管我没有负责更新大型网站），
- 将IP封锁页面改为引用其自身的http-refresh 5秒。
- 在 IP 限制中放置通配符。
- 上传更改。
- 解除 IP 封锁。
我发现它工作高效且良好 - 许多用户甚至没有意识到更新期间有任何停机时间。如果您经营一家商店或类似业务，那么诚实地在错误页面上写上“我们正在进行网站更新，2 分钟内恢复在线”等可能是个好主意。
此外，以上内容假设您已经测试了更改并且它运行良好 - 您将要做的只是一些不会花费很长时间的文件操作。