logo标签列表

WordPress网站发布管理策略

phpmysqlwordpressbuild-automationrelease-management
7
我正在更新一个现有的WordPress网站，对主题和网站结构进行了重大修改，同时更新插件，这些插件将其数据存储到MySQL数据库中。
据我所知，这里有2（3？）种可能的策略：
1. 从DEV到LIVE“转储并加载”MySQL数据库，并用最新的更新替换wp-content文件夹。 2. 通过WP导入器导入更改，并用最新的更新替换wp-content文件夹。 3. 通过WP管理界面手动进行数据库更改，并用最新的更新替换wp-content文件夹（仅适用于小的更改）。
虽然我正在自己独立的环境中开发，但这是一个现有的网站，目前正在运行，并将继续接收来自公众的更新，如评论和联系表单条目，因此我预计数据库现在与发布我的更改时不同。
鉴于此，上述选项存在以下问题。
1. 转储并加载
“转储和加载”策略似乎行不通，因为我的数据正在幕后更新（这本应是我的首选方法，因为它很容易回滚）。
结果：需要在发布后同步数据库以获取最新的更新，过于复杂。

2. 使用导入插件

使用WP-Importer插件页面和文章ID将被更新，会破坏依赖于文章ID激活的样式。这反过来又创造了一个CSS噩梦，我希望避免，在发布之后必须经过CSS以更新新页面/文章ID与数据库创建的那些。

结果：太过挑剔，不是非常专业的方法，导致发布过程冗长且复杂。

3. 手动更新数据库

这个选项对于小改动很棒，但对于更复杂的发布，需要在PROD界面上遵循一系列步骤，这会变得冗长而难以遵循，容易出错。

结果：太容易出错，只是最后的手段。

是否有标准的WordPress现有网站发布策略？

基本上，我的问题是：其他WordPress开发人员在更新现有网站时遵循什么发布流程？是否有我没有列出的选项可以最大程度地减少麻烦并减少发布时间和复杂性？

我已经使用GIT为网站设置了源代码控制，并且习惯于通过ANT或类似的发布脚本自动化事务，尽管这可能对当前项目来说有些过头，但至少知道一种简单的更新WordPress网站并最大程度地减少出错的可能性是理想的。
谢谢！
3
我不喜欢WordPress的另一个原因。 - cegfault
1
我非常确定我在WordPress StackExchange上看到过这个问题被讨论了不止一次。 - brasofilo
真是太神奇了，现在他们甚至为WordPress设立了一个堆栈交换平台。 - Steven de Salas
3个回答
2
我认为这不仅适用于WordPress，也适用于任何自定义网站。我个人更喜欢在生产环境上重放在开发环境中进行的SQL更改。棘手的部分是您必须知道进行了哪些SQL更改。例如，某个插件在安装时可能会进行一些模式更改-您需要知道它们是什么。您可以通过在安装插件之前创建一个将数据库导出为SQL文件的方法，然后再次导出并对文件进行差异比较来实现这一点。
由于您说您正在进行修改，因此我可能会假设您知道要进行哪些SQL更改？只需确保您对DB所做的所有更改都以SQL脚本文件的形式而不是仅使用GUI进行编辑（您可以使用GUI帮助编写查询，但保存实际的SQL）。完成所有更改后，您应该有一堆在开发过程中运行的SQL脚本-您可以按顺序重新运行它们而不会遇到错误。
然后，在推送到生产环境时，请创建生产的暂存版本（即获取生产的相当当前的DB备份）。在其中运行更新脚本并测试一切是否正常。如果是，则可以在生产环境上运行。
在对其进行任何更改之前，一定要备份生产环境！
在进行更改之前和之后，在DEV数据库上进行DIFF操作，这是一个绝妙的想法。 - Steven de Salas
2

无需多言，你还有其他选择。如果你正在手动进行数据库更改，请确保有效地处理序列化数据。我建议使用Search and Replace DB。WordPress也有一个非常好用的技巧，可以从wp-config文件中完全更改站点URL。

在编程中，对于WP_HOME/WP_SITEURL变量的加1以及使用Search + Replace DB脚本修复序列化数据是非常重要的。 - Steven de Salas
1
我知道这是一个2012年的答案，但是检查一下相对较新的wp-cli命令来进行搜索和替换任务是非常值得的，它非常容易使用。一个用于此的wp-cli命令示例是： wp search-replace http://somesite.com https://somesite.com --dry-run -- 一旦您测试并检查了输出，请省略--dry-run。 - Brian C
2

我假设您已经在测试环境中运行了所有内容。然后我会：

  • 在您的生产环境中创建一个新的数据库。
  • 预加载所有新站点的内容和配置。
  • 在测试环境中，将config.php配置为指向新数据库。
  • 上传所有文件到生产服务器。最后上传config.php。

这将最小化停机时间。

这似乎是你的数据在幕后被更新导致的问题。 - Maarten
好的建议，谢谢。如果选择上述第三个选项（手动更改数据库），将最小化停机时间。 - Steven de Salas
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接