使用Bitbucket进行WordPress连续部署和版本控制

本文概述

WordPress连续部署做错了
Alexa Green WordPress部署例程
跨安装同步WordPress数据库
本文总结

好的, 伙计们。是时候来” fess up” 了。
如果你像我一样, 则是在WordPress开发年代的第一阶段” 牛仔编码” , 也就是说, 在实时站点上疯狂地进行更改, 紧急测试并使用FTP激活它们, 通常会导致500条内部服务器错误消息和网站范围内的所有内容都对你尊敬的访问者可见。
当肾上腺素通过你的手指抽动, 敲打那个被遗忘的分号时, 这绝对是令人激动的, 在访客超过0(实际上注意到停机)的站点上, 这将成为一个问题。如果一棵树倒下而没人在那里听到, 它会发出声音吗？取决于你所订阅的人文理论。
但是, 如果某个站点崩溃了, 并且有人在那里看到它, 那么他们肯定会发出声音。
WordPress连续部署做错了输入暂存站点, 复制WordPress安装(至少在理论上是可以进行更改的), 然后在实时站点中再次确认所有工作都可以进行更改。虽然这使访客安静下来, 但它开始引起我们开发人员的注意。突然, 我们需要跟踪两个站点, 确保在两个站点之间手动同步代码, 然后再次测试所有内容以确保它在实际站点上正常工作。至少, 至少可以说, 冗长而混乱的清单” 确保实时更改” 和” 确保在复制代码之前在登台站点上对此进行切换” 。该系统的备份也是一个噩梦–名为” my-theme-staging-1″ 和” my-theme-live-before-menu-restyle-3″ 的大量文件夹等等。
必须有更好的方法, 而且确实存在。
有Git, 它为开发人员提供了完善的源代码控制和其他功能。将版本控制用于WordPress安装可立即加快工作速度, 并清理开发过程, 因为不再需要花费数小时在每个开发人员系统中进行备份, 而实际上是在编码方面。更改得以保存, 我终于可以在我的工作中添加有意义的信息, 这与” my-theme-4-v2″ 世界有所不同。
尽管代码库要干净得多, 但实际部署仍然存在问题, 并确保所涉及的站点正在使用最新代码-避免出现人为错误的机会。仍然依靠手动FTP上传来覆盖以前的代码, 感觉并不好。尽管还存在其他CI / CD服务, 但其中许多服务都带有高昂的价格和大量的设置-服务器重新定价, 即使是最简单的网站也要依赖另一种服务, 还要学习另一种服务的整体” 做事方式” 以及所有随之而来的特质。
尽管可以使用GitHub / GitLab和其他服务来完成与本教程类似的设置, 但由于它们具有免费的私有存储库(这只是GitHub的最新产品), 所以我早就将其放在了Atlassian篮子中。当Bitbucket推出其管道和部署服务时, 它允许新代码自动部署到暂存或生产站点(或中间的任何其他站点), 而无需通过FTP或使用外部服务重新上传。开发人员现在可以在其WordPress开发中使用源代码管理的所有值, 并立即将这些更改发送到适当的目的地, 而无需额外的单击或击键, 并且所有内容的状态都可以通过一个仪表板看到。这样可以确保一切保持同步, 并且一眼就能知道每个站点正在运行的代码。此外, Bitbucket的构建分钟价格令人难以置信-每月免费提供50分钟, 并且可以选择” 免费提供超量服务” 。
花费了一些启动时间才能弄清楚如何在此新模型中以及在Bitbucket Pipelines设置的详细信息中最佳利用分支和源代码管理的其他功能。这是我用于启动新WordPress项目的过程。我不会深入探讨设置git和WordPress安装的问题, 因为有关这方面的大量资源仅需Google搜索即可。最后, 内容流将如下所示：

文章图片
Alexa Green WordPress部署例程这里概述的步骤应根据需要执行：
在客户端的服务器上
设置实时站点的域(例如, clientsite.com)和用于登台的子域(例如, staging.clientsite.com)。
在实时站点和暂存子域上都安装WordPress。可以通过cPanel / Softaculous(如果客户端的托管服务器具有此功能)或从wordpress.org下载来完成。确保分别有单独的数据库用于直播和登台。
在Bitbucket.com上
设置一个新的存储库。包括一个.README可使我们起步。

文章图片
在存储库中, 设置> 管道> 设置, 然后选中启用管道。

文章图片

文章图片
在设置> 管道> 存储库变量中, 输入以下内容：

Name: FTP_username Value: The client FTP username

Name: FTP_password Value: The client FTP password

文章图片
返回管道> 设置, 然后单击配置bitbucket-pipelines.yml按钮。在下一页上, 选择PHP作为语言。你将要使用类似以下代码的内容。确保用客户端服务器上使用的任何版本替换PHP版本, 并使用实际客户端站点(生产和登台)的URL / FTP服务器替换URL / FTP服务器。

image: php:7.1.29pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp init --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com

文章图片
单击提交文件。管道设置现在将提交并运行。
如果一切都成功部署, 请返回并编辑bitbucket-pipelines.yml文件(可以通过” 管道” > ” 设置” 并查看” bitbucket-pipelines.yml” 到达该文件)。你需要将git ftp init的两个地方都替换为git ftp push并保存/提交。这样可以确保仅上传已更改的文件, 从而节省了构建时间。你的bitbucket-pipelines.yml文件现在应显示为：

image: php:7.1.29pipelines: branches: master: - step: name: Deploy to production deployment: production script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com main-dev: - step: name: Deploy to staging deployment: staging script: - apt-get update - apt-get -qq install git-ftp - git ftp push --user $FTP_username --passwd $FTP_password ftp://ftp.clientsite.com/staging.clientsite.com

文章图片
添加一个名为main-dev的分支。
在本地计算机上
将存储库克隆到你要用于本地安装的空目录中。检出main-dev分支。
在此目录中设置本地WP安装。为此有很多工具-Flywheel, MAMP, Docker等在本地。请确保所有内容都与客户端服务器上运行的内容相同(WordPress版本, PHP版本, Apache / Nginx等)。
添加一个看起来像这样的.gitignore。本质上, 我们希望Git忽略除wp-content之外的所有内容(以防止安装之间出现安装问题)。你可能还想添加自己的规则, 以忽略大型备份文件以及系统创建的图标和DS_Store文件。

# Ignore everything * # But not .gitignore !*.gitignore # And not the readme !README.md # But descend into directories !*/ # Recursively allow files under subtree !/wp-content/** # Ignore backup files # YOUR BACKUP FILE RULES HERE # Ignore system-created Icon and DS_Store files Icon? .DS_Store # Ignore recommended WordPress files *.log .htaccess sitemap.xml sitemap.xml.gz wp-config.php wp-content/advanced-cache.php wp-content/backup-db/ wp-content/backups/ wp-content/blogs.dir/ wp-content/cache/ wp-content/upgrade/ wp-content/uploads/ wp-content/wflogs/ wp-content/wp-cache-config.php # If you're using something like underscores or another builder: # Ignore node_modules node_modules/ # Don't ignore package.json and package-lock.json !package.json !package-lock.json

保存并提交.gitignore。
进行更改并相应地提交。
每当你提交main-dev时, 都会将FTP上传到登台站点。只要你承诺掌握, 它就会将FTP上传文件上传到生产站点。请注意, 这将占用构建时间, 因此你可能要在main-dev的分支上进行大多数本地更改, 然后在当天完成后合并到main-dev。
将main-dev合并到master将使所有暂存更改生效。你可以在Bitbucket.org的存储库上检查管道和部署的状态。

文章图片

文章图片
跨安装同步WordPress数据库请注意, 上述内容仅会同步文件(主题, 插件等)。在生产和登台之间同步数据库变得不同, 因为客户经常在实时站点上进行未在登台站点上反映的更改, 反之亦然。
为了在WordPress安装之间同步数据库, 存在多个选项。传统上, 你可以通过phpmyadmin导入/导出来更新数据库。但是, 这很棘手, 因为它无法更新某些需要更新的内容, 例如帖子内容中的永久链接。使用此方法, 最喜欢的工具是Velvet Blues Update URLs插件, 你可以使用该插件将旧站点URL(例如https://staging.clientsite.com)的任何实例搜索/替换为新站点URL(例如https://clientsite.com)。你也可以将其与相对路径和字符串一起使用。这种方法最终会留出很多人为错误的空间-如果替换的字符串写错了, 则可能导致整个站点中断, 并且无法使用插件/访问仪表板。
虽然像All-in-one WP Migration这样的插件提供了开箱即用的搜索/替换功能, 并且非常易于使用, 但它也带来了文件, 从而取消了整个Pipelines工作流程的价值。另外, 由于它会重新导入所有wp-upload, 因此会导致文件和加载时间过长(因此不适合跨安装移动更改)。最好将这样的插件保留用于整个站点的备份, 以用于存档/安全性目的。
VersionPress似乎是一个有趣的解决方案, 但尚未在许多生产环境中得到验证。目前, WP Sync DB或WP Migrate DB Pro之类的插件似乎是数据库管理的最佳解决方案。它们允许跨安装拉/推数据库, 同时提供自动更新URL和路径的选项。他们只能迁移某些表, 例如wp_posts仅用于发布内容, 而不会浪费时间重新导入用户和站点范围设置。我喜欢始终撤出现场以确保没有生产数据被覆盖。如果你使用的是WP Sync DB, 则这是一个示例设置(WP Sync DB github上提供了更多演练)：

在实时站点上：启用” 允许从此存储库中提取” 设置, 设置WP Sync DB。
在登台站点上：使用” 实时直播” 设置来设置WP Sync DB。将其命名为” 实时运行” 。
在本地开发人员设置中：使用” 实时直播” 设置设置WP Sync DB。将其命名为” 实时开发” 。

你可能还需要设置一个强制性的” 开发到暂存” 规则, 并检查暂存站点设置以允许覆盖数据库。
本文总结我发现这些方法通常适用于大多数用例, 包括开发新的WordPress网站和重新设计/重新设计已经存在的网站。
它允许进行代码部署, 以使所有站点版本保持最新状态, 而无需增加开发时间/精力, 并且可以在站点之间进行有目的, 安全的数据库迁移逻辑。更新插件也是在源代码控件中完成的, 因此可以在提交到现场站点之前在阶段中安全地检查插件更新, 从而最大程度地减少生产站点的中断。
【使用Bitbucket进行WordPress连续部署和版本控制】虽然肯定还有改进的余地, 以便将更多的源代码控制工作流程引入数据库管理, 但是直到在生产环境中使用像VersionPress这样的工具之前, 这种通过WP Sync DB或WP Migrate DB Pro选择性地拉/推数据库的方法似乎是处理此问题的最安全方法。好奇地想知道哪种方法适用于你的WordPress工作流程, 或者毕竟, 你只是想索取套索和牛仔代码吧！