在生产中运行 Wordpress 更新？答案

【问题标题】：Running Wordpress updates while in production?在生产中运行 Wordpress 更新？
【发布时间】：2013-08-10 01:05:56
【问题描述】：

我们有一个由 Wordpress 提供支持的生产站点。以我的经验，Wordpress 更新往往非常顺利，但时不时会出现问题，因此我们总是首先在本地或我们的开发网站上运行更新，以确保没有任何问题。

我的问题是：在本地提交这些更改（来自升级）然后将更改推送到生产环境是一种好习惯吗？ ...有效地更新生产现场？这似乎有效，但我知道有时更新包括对数据库的修改。所以我担心更新会修改我的本地数据库，而不是生产数据库，然后在新代码运行时导致问题（预计数据库已被修改）。

这是有效的担忧吗？
编写良好的插件会以某种方式解决此问题吗？
有没有完全不同的更好的方法来做到这一点？

更新： 我认为这个问题的目的最初并不清楚。我很清楚我可以在本地运行更新，测试它，提交，然后在生产中运行更新，提交，然后合并。这就是我们目前所做的，但它很糟糕，我不确定它是否有必要。这个问题的重点是弄清楚这一点，或者学习更好的方法。例如，如果有人知道关于 WP 更新的性质以及他们如何处理数据库修改的确切信息，那么它几乎可以回答这个问题。

【问题讨论】：

这是 WP 特有的。也许是 wordpress.stackexchange.com？我认为更新不会与任何可能破坏网站的数据库混淆，除非您弄乱了核心内容。在处理 3.6 和我的自定义表格时，我一直害怕同样的事情......它们没有受到影响。
使用 wordpress 和 drupal，我已经从更新中冲洗了一些网站。与尝试找出问题相比，回滚提交和恢复数据库所花费的时间更少。是的，一些模块和一些核心更新有数据库更改，但不是每次都更改。花时间在本地更新/测试/提交/推送是一件痛苦的事，但在出现问题时值得。我看到的问题是插件相互冲突，尤其是在一个更新之后。

标签： php mysql wordpress

【解决方案1】：

如果您能够在测试环境中成功执行更新，那么您应该能够在生产环境中执行相同的更新。这可能需要更多的工作，但它会为您提供有关更新是否有效的最多信息。

如果您处于虚拟化环境中，您应该能够复制生产虚拟机来测试升级。

【讨论】：

我们遇到的问题是，一旦更新在本地运行，我们宁愿将这些更改推送到生产环境，而不是在生产环境中再次运行更新，然后必须合并这些更改.这就是我们目前所做的，但这似乎是多余的。这就是我发布这个问题的原因。

【解决方案2】：

即使需要多花几分钟时间，也要始终坚持最佳做法。在本地完成更新，然后推送到开发站点。有时，插件会更改数据库但未正确记录。

最佳实践：

在更新后等待一天，然后阅读插件上的问题队列。如果其他人在更新时遇到问题，您会提前知道的。
备份数据库
git status/git commit，确保分支是干净的/进行任何需要的提交
完成所有必要的更新
清除所有缓存（两次）
检查以确保一切都在本地顺利运行。
如果更新后数据库发生了变化 进行新的数据库备份。
将更改推送到开发站点
如果有数据库更改从 #7 恢复数据库

编辑：请确保您的本地数据库和代码与备份前的开发站点相同。

【讨论】：

【解决方案3】：

我更喜欢像 WP Staging 这样的工具，只需点击几下即可创建测试站点。比我更新所有插件，如果一切正常，我会在我的生产站点上执行相同的过程。您可以在 wordpress.org 上找到 WP Staging

【讨论】：

【解决方案4】：

只需确保在执行任何操作之前保存一份工作副本即可。此外，请始终检查更新是什么，有时它只是您可能不需要的语言插件。

【讨论】：