Okay, folks. Time to ‘fess up.

如果你像我一样，你度过了你的第一段 WordPress development 多年的“牛仔编码”——就是这样, 在现有的网站上做出巨大的改变, 紧急测试并使用FTP启动它们, 通常会导致500个内部服务器错误消息和站点范围内的中断，所有这些都是您尊敬的访问者可见的.

当肾上腺素从手指间流过时，这绝对是令人兴奋的, 敲进那个被遗忘的分号, 在超过0个访问者的网站上(他们实际上注意到了停机时间)，这将开始成为一个问题. 如果一棵树倒了，没有人听见，它会发出声音吗? 这取决于你所认同的人性理论.

然而，如果一个网站崩溃了，有人在那里看到它，他们肯定会发出声音.

WordPress持续部署错了

Enter staging sites, 重复WordPress安装(至少在理论上)，在那里可以进行更改, 然后在现场再次制作，一旦所有确认工作. 虽然这让访问者安静下来，但它开始引起我们开发人员的一些噪音. Suddenly, 我们需要跟踪两个地点, 确保代码在它们之间手动同步, 再测试一次，确保它能在现场正常运行. Long, “确保在现场更改这个”和“确保在复制代码之前在登台站点切换这个”的杂乱列表令人伤脑筋, to say the least. 这个系统的备份也是一场噩梦——一大堆名为“my-theme- stage -1”和“my-theme-live-before-menu- style-3”的文件夹，等等.

肯定有更好的办法，而且确实有.

有Git，它为开发人员提供了完美的源代码控制和其他特性. 对WordPress安装使用版本控制可以立即加快和清理开发, 因为时间不再花在每个开发人员系统的备份上，而是花在编码上. 更改被保存下来，我终于可以在我的工作中添加有意义的信息, 与“my-theme-4-v2”截然不同.”

而代码库则干净多了, 实际部署的问题仍然存在，并确保有问题的站点使用了最新的人为错误代码输入机会. 仍然依赖手动FTP上传，覆盖之前的代码，感觉不太好. 而其他CI/CD服务已经存在, 它们中的许多都有相当大的价格标签和大量的设置服务器重新配置, 即使是最简单的网站也要依赖另一种服务, 学习其他服务的整个“做事方式”以及随之而来的所有特质.

与本教程类似的设置可以用GitHub/GitLab和其他服务完成, 由于Atlassian的免费私有存储库(GitHub最近才提供)，我很早就把鸡蛋放在了Atlassian的篮子里。. When Bitbucket introduced their 管道和部署 services, 它允许新代码自动部署到登台站点或生产站点(或介于两者之间的任何其他站点)，而无需通过FTP或使用外部服务重新加载. 开发者现在可以在他们的WordPress开发中使用源代码控制的所有价值，并立即将这些更改发送到适当的目的地，而无需额外的点击或击键, 所有的状态都可以通过一个仪表板看到. 这确保了一切保持同步和, at a glance, 让您确切地知道每个站点正在运行的代码. Plus, the pricing 因为Bitbucket的构建时间非常实惠——每月50分钟免费，还有一个“超期免费”计划的选项.

我们花了一些启动时间来弄清楚如何在这个新模型中最好地使用分支和源代码控制的其他特性，以及Bitbucket pipeline设置的细节. 下面是我开始新的WordPress项目的过程. 我不会详细介绍安装git和WordPress的所有细节，因为在谷歌上搜索一下就能找到很多相关的资源. 最后，内容流将是这样的:

Alexa绿色WordPress部署例程

应根据需要执行以下步骤:

On the Client’s Server

为活动站点设置域(例如.g., clientsite.Com)和用于暂存的子域(例如.g., staging.clientsite.com).

在活动站点和暂存子域上都安装WordPress. 这可以通过cPanel/Softaculous(如果客户端的主机有这个)或通过从wordpress下载.org. 确保有单独的数据库分别用于实时和暂存.

On Bitbucket.com

设置一个新的存储库. Include a .README让我们振作起来.

In the repository, Settings > Pipelines > Settings then check Enable Pipelines.

In Settings > Pipelines > Repository variables，输入如下:

Name: FTP_username
取值范围:客户端FTP用户名

Name: FTP_password
取值范围:客户端FTP密码

Go back to Pipelines > Settings and click the 配置bitbucket-pipelines.yml button. Select PHP 作为下一页的语言. 您将需要使用以下代码. 确保将PHP版本替换为您在客户端服务器上使用的任何版本, 和url /FTP服务器与实际的客户端站点(生产和登台)url /FTP服务器.

image: php:7.1.29

pipelines:
 branches:
   master:
     - step:
         名称:部署到生产环境
         部署:生产
         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:部署到暂存
         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

Click Commit file. 管线设置现在将被提交并运行.

如果一切都部署成功，返回并编辑比特桶管道.Yml文件(您可以通过 Pipelines > Settings and 视图bitbucket-pipelines.yml). 你会想把这两个地方都替换掉 git ftp init with git ftp push and save/commit. 这将确保只上传更改过的文件，从而节省构建时间. 你bitbucket-pipelines.Yml文件现在应该是:

image: php:7.1.29

pipelines:
 branches:
   master:
     - step:
         名称:部署到生产环境
         部署:生产
         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:部署到暂存
         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

Add a branch called main-dev.

On Your Local Machine

将存储库克隆到您希望用于本地安装的空目录中. Check out the main-dev branch.

在此目录中设置本地WP安装. 有很多工具可以做到这一点Local by Flywheel, MAMP, Docker, etc. 确保所有内容都是相同的(WordPress版本，PHP版本，Apache/Nginx等).)作为在客户端服务器上运行的内容.

Add a .gitignore 它看起来像这样. 本质上，我们希望Git忽略除了wp-content之外的所有内容(以防止安装之间的安装问题). 您可能还想添加自己的规则来忽略大型备份文件和系统创建的图标以及DS_Store文件.

# Ignore everything
*
# But not .gitignore
!*.gitignore
# And not the readme
!README.md
#但是下降到目录
!*/
#递归允许子树下的文件
!/wp-content/**
# Ignore backup files
#您的备份文件规则在这里
#忽略系统创建的Icon和DS_Store文件
Icon?
.DS_Store
#忽略推荐的WordPress文件
*.log
.htaccess
sitemap.xml
sitemap.xml.gz
wp-config.php
wp-content /高级高速缓存.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
#如果你正在使用下划线或其他构建器:
# Ignore node_modules
node_modules/
#不要忽略包.json and package-lock.json
!package.json
!package-lock.json

Save and commit .gitignore.

做出改变并相应地提交.

每次提交到main-dev时，它都会触发一次FTP上传到暂存站点. 每次提交到master时，它都会触发一个FTP上传到生产站点. 注意，这将使用构建分钟, 因此，您可能希望在main-dev的分支上进行大多数本地更改, 一旦你完成了一天的工作，就合并到main-dev.

将主开发合并到主开发中会使所有的分级更改实时生效. 您可以在Bitbucket上的repo上查看管道和部署的状态.org.

跨安装同步WordPress数据库

注意，上面只会同步文件(主题，插件等). 在生产和登台之间同步数据库是另一回事, 客户经常在活动站点上进行更改，而这些更改不会反映在登台站点上, and vice versa.

要跨WordPress安装同步数据库，有几个选项. 传统上，您可以通过导入/导出来更新数据库 phpmyadmin. This is tricky though, 因为它不能更新某些需要更新的东西, 比如帖子内容中的永久链接. 使用这种方法，最喜欢的工具是 天鹅绒蓝调更新url插件，然后您可以使用它来搜索/替换旧站点URL的任何实例(例如.g., http://staging.clientsite.. com)转到新的网站网址(e.g., http://clientsite.com). 你也可以使用相对路径和字符串. 这种方法最终为人为错误留下了很大的空间——如果被替换的字符串写错了, 它可能导致整个网站崩溃，无法使用插件/访问仪表板.

While a plugin like 一体化WP迁移 提供了一个开箱即用的搜索/替换功能，并且非常友好, 它还带来了文件, 因此撤销了我们整个管道工作流的值. Plus, 因为它重新导入了所有的wp上传, 它可能导致巨大的文件和加载时间(因此不适合跨安装移动更改)。. 为了存档/安全的目的，最好为整个站点的备份保留这样的插件.

VersionPress 这似乎是一个有趣的解决方案，但它还没有在很多生产环境中得到验证. For now, plugins like WP Sync DB or WP Migrate DB Pro 似乎是数据库管理的最佳解决方案. 它们允许跨安装拉/推数据库，同时提供自动更新url和路径的选项. 它们只能迁移某些表, 像wp_posts一样，仅用于发布内容, 不浪费时间重新导入用户和站点范围的设置. 我总是喜欢从现场提取数据，以确保没有生产数据被覆盖. 这里有一个示例设置，如果你正在使用WP Sync DB(更多演练可在 the WP Sync DB github):

1. On the live site: 将WP Sync DB设置为“允许从此存储库中提取”.
2. On the staging site: 设置WP Sync DB从实时设置拉. 将其命名为“live-to- stage”.”
3. 在本地开发设置中: 设置WP Sync DB从实时设置拉. Name it “live-to-dev.”

您可能还想设置“从开发到登台”的推入规则, 并检查暂存站点设置以允许覆盖数据库.

Wrapping Up

我发现这些方法适用于大多数用例, 无论是开发一个新的WordPress网站，还是重新设计/重新配置一个已经上线的网站.

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

当然，在将源代码控制工作流引入数据库管理方面还有改进的空间, 直到像VersionPress这样的工具在生产环境中被更多地使用，这种通过WP Sync DB或WP Migrate DB Pro选择性地拉/推数据库的方法似乎是处理这个问题最安全的方法. 很想知道什么适合你的WordPress工作流程, 或者，在这一切之后，您宁愿拿起套索并对其进行牛仔编码!