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

已发表: 2022-03-11

好的，伙计们。是时候坦白了。

如果你和我一样，你在 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 和其他服务来完成与本教程类似的设置，但我很早就将我的鸡蛋放在 Atlassian 篮子里，因为它们有免费的私有存储库（这只是 GitHub 的最新产品）。当 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 让我们振作起来。

在存储库中， Settings > Pipelines > Settings然后选中Enable Pipelines 。

在Settings > Pipelines > Repository variables中，输入以下内容：

 Name: FTP_username Value: The client FTP username

 Name: FTP_password Value: The client FTP password

返回Pipelines > Settings并单击Configure bitbucket-pipelines.yml按钮。在下一页上选择PHP作为语言。您将需要使用类似以下代码的内容。确保将 PHP 版本替换为您在客户端服务器上使用的任何内容，并将 URL/FTP 服务器替换为实际的客户端站点（生产和暂存）URL/FTP 服务器。

 image: php:7.1.29 pipelines: 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

单击提交文件。 Pipelines 设置现在将被提交并运行。

如果一切部署成功，返回并编辑 bitbucket-pipelines.yml 文件（您可以通过Pipelines > Settings和View bitbucket-pipelines.yml到达那里）。您需要用git ftp push和 save/commit 替换上面写着git ftp init的两个地方。这将确保仅上传更改的文件，从而节省您的构建时间。您的 bitbucket-pipelines.yml 文件现在应为：

 image: php:7.1.29 pipelines: 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 上传到登台站点。任何时候你提交到 master，它都会触发一个 FTP 上传到生产站点。请注意，这将使用构建分钟数，因此您可能希望在 main-dev 的分支上进行大多数本地更改，然后在当天完成后合并到 main-dev。

将 main-dev 合并到 master 将带来所有暂存更改。您可以在 Bitbucket.org 上的 repo 上查看 Pipelines 和 Deployments 的状态。

跨安装同步 WordPress 数据库

请注意，以上只会同步文件（主题、插件等）。在生产和登台之间同步数据库变成了另一回事，因为客户经常在实时站点上进行未反映在登台站点上的更改，反之亦然。

对于跨 WordPress 安装同步数据库，存在几个选项。传统上，您可以通过phpmyadmin导入/导出来更新数据库。不过这很棘手，因为它无法更新某些需要更新的内容，例如帖子内容中的永久链接。使用这种方法，最喜欢的工具是 Velvet Blues Update URLs 插件，然后您可以使用它来搜索/替换旧站点 URL 的任何实例（例如，https://staging.clientsite.com）到新站点 URL（例如，https://clientsite.com）。您也可以将其与相对路径和字符串一起使用。这种方法最终为人为错误留下了很大的空间——如果替换的字符串写错了，它可能导致整个站点崩溃并且无法使用插件/访问仪表板。

虽然像 All-in-One WP Migration 这样的插件提供了开箱即用的搜索/替换功能并且非常用户友好，但它也带来了文件，从而取消了我们整个 Pipelines 工作流程的价值。另外，由于它重新导入所有 wp-uploads，它可能会导致巨大的文件和加载时间（因此它不适合跨安装移动更改）。像这样的插件最好保留用于备份整个站点以用于存档/安全目的。

VersionPress 似乎是一个有趣的解决方案，但尚未在许多生产环境中得到证明。目前，WP Sync DB 或 WP Migrate DB Pro 等插件似乎是数据库管理的最佳解决方案。它们允许跨安装拉/推数据库，同时提供自动更新 URL 和路径的选项。他们只能迁移某些表，例如仅用于发布内容的 wp_posts，而不会浪费时间重新导入用户和站点范围的设置。我喜欢总是从现场拉出来，以确保没有生产数据被覆盖。如果您使用的是 WP Sync DB，这是一个示例设置（更多演练可在 WP Sync DB github 上找到）：

在实时站点上：设置 WP Sync DB 并启用“允许从此存储库中提取”设置。
在临时站点上：设置 WP Sync DB 与 Pull from Live 设置。将其命名为“现场直播”。
在您的本地开发设置上：设置 WP Sync DB 与从实时设置中提取。将其命名为“live-to-dev”。

您可能还想设置一个推送“dev-to-staging”规则，并检查暂存站点设置以允许覆盖数据库。

包起来

我发现这些方法往往适用于大多数用例，无论是开发新的 WordPress 网站还是重新设计/重构已经存在的网站。

它允许代码部署使所有站点版本保持最新，而无需增加开发时间/精力和用于在站点之间工作的有意、安全的数据库迁移逻辑。更新插件也在源代码控制中完成，因此可以在提交到实时站点之前安全地检查插件更新，从而最大限度地减少生产站点中断。

虽然将更多的源代码控制工作流引入数据库管理当然还有改进的余地，但在生产环境中更多地使用像 VersionPress 这样的工具之前，这种通过 WP Sync DB 或 WP Migrate DB Pro 选择性地拉/推数据库的方法似乎成为处理此问题的最安全方法。很想知道什么适用于您的 WordPress 工作流程，或者如果在所有这些之后您宁愿抓住您的套索和牛仔代码！