Ste*_*las 7 php mysql wordpress build-automation release-management
我正在更新现有的wordpress网站,对主题和网站结构进行重大修改,以及对插件进行更新,然后插件将数据存储到mysql数据库中.
据我所知,这里有2(3?)种可能的策略:
虽然我在自己独立的环境中开发,但这是针对现有网站,该网站目前正在进行,并将继续接收来自公众的更新,例如评论和条目到联系表单,因此我希望数据库现在与我发布时不同我的变化.
鉴于此,上述选项提供了以下问题.
1.转储和负载
"转储和加载"策略似乎是不可能的,因为我的数据正在幕后更新(这可能是我的首选方法,因为这很容易回滚).
结果:要求在发布后同步数据库以获取最新更新,TOO COMPLICATED.
2.使用进口商
使用WP-Importer插件页面和帖子ID将得到更新,搞砸依赖于帖子ID的样式来激活.这反过来会产生一个我想避免的CSS噩梦,在发布之后必须通过CSS 来更新数据库创建的新页面/帖子ID.
结果:太挑剔,不是非常专业的方法导致漫长而复杂的发布过程.
3.手动更新数据库
此选项适用于较小的更改,但是对于更复杂的版本,PROD界面上要遵循的步骤列表变得冗长且难以遵循,从而容易出错.
结果:太容易搞砸,只是万不得已.
对于现有的网站,是否有标准的WORDPRESS发布战略?
基本上,我的问题是:在更新现有网站时,其他wordpress开发人员会遵循哪些发布流程?是否有一个我未在下面列出的选项可以最大限度地减少麻烦并减少发布期间的时间和复杂性?
我已经使用GIT为网站设置了源代码控制,我习惯通过ANT或类似的发布脚本自动化这些东西,这对于当前项目来说可能有些过时,但至少知道更新wordpress的简单方法是理想的网站,并尽量减少搞砸的机会.
谢谢!
我认为这并不是 WordPress 所特有的,任何自定义网站的情况都类似。我个人更喜欢在生产环境中重放在开发环境中所做的 SQL 更改。棘手的部分是您必须知道 SQL 发生了哪些更改。例如,某个插件在安装时可能会进行一些架构更改 - 您需要知道它们是什么。为此,您可以在安装插件之前将数据库创建为 SQL 导出,然后再进行一次导出并对文件进行比较。
既然您说您正在进行修改,那么我可能会假设您知道要进行哪些 SQL 更改?只需确保您对数据库所做的所有更改都是 SQL 脚本文件的形式,而不仅仅是使用 GUI 进行编辑(您可以使用 GUI 来帮助编写查询,但保存实际的 SQL)。完成所有更改后,您应该拥有在开发过程中运行的一堆 SQL 脚本 - 您可以按顺序重新运行它们,而不会遇到错误。
然后,当需要推送到生产环境时,创建生产环境的暂存版本(即获取生产环境的最新数据库备份)。运行更新脚本并测试一切正常。如果是,那么您可以在生产环境中运行。
在对其进行任何更改之前,一定要对生产环境进行备份!
归档时间: |
|
查看次数: |
970 次 |
最近记录: |