0

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

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

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

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

4

4 回答 4

1

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

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

于 2013-08-10T01:15:51.017 回答
1

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

最佳实践：

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

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

于 2013-08-10T01:32:08.987 回答
1

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

于 2016-01-07T11:30:25.773 回答
-1

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

于 2013-08-10T01:14:50.843 回答