前言：
持续集成(CI)工作流程被认为是目前最佳的开发方式。我们在开发过程中会用版本控制系统(Git)来管理代码版本。同时CI会帮助我们运行测试、发送通知和部署代码。借助GitHub Actions，个人项目以及小微项目都可以拥有免费的CI/CD服务。
对于WordPress开发而言，使用持续集成与持续交付策略可以让开发者更灵活的应对变化多端的需求，甚至在网站上线后，对网站持续开发。
下面让我们来看看如何使用GitHub Actions进行WordPress CI/CD。
持续部署的基本工作流程
当我们将代码提交到一个共享的远程仓库，比如GitHub，每一次推送到它，都会在远程服务器上运行自动化任务。这些任务可能包括测试和构建过程，比如linting、concatenation、minification和image优化等等。CD也会将代码传送到生产服务器上。这可能是通过复制已验证和构建的代码，并通过FTP、SSH将其放置在服务器上。
如何使用rsync进行部署
一个简单有效的方法实现rsync是通过SSH将文件传送到服务器，这是一个在源目录与目标目录、驱动器与计算机之间实现同步文件的实用工具。它只会同步那些已经改变了的文件或者在目的地还不存在的文件。由于它成为了流行的Linux发行版的标准工具，所以你很有可能根本不需要安装它。
最基本的操作就像调用rsync SRC DEST将文件从一个目录同步到另一个目录一样简单。然而，有几个选项我们需要知道:
-c 通过校验和而不是修改时间来比较文件的变化。
-h 以更易读的格式输出数字。
-a 保留文件属性和权限，并递归复制文件和目录。
-v 显示状态输出
--delete 删除在源文件中找不到的目标文件。
--exclude 防止同步指定的文件，如.git目录和node_modules。
最后，我们需要把文件发送到远程服务器，完整的命令如下：
rsync -chav --delete --exclude /.git/ --exclude /node_modules/ ./ ssh-user@example.com:/mydir
创建GitHub Action工作流
通过GitHub Actions，我们可以配置工作流来运行在任何GitHub事件上。
首先，我们进入版本库的 "Actions" 标签，然后点击 "Set up a workflow yourself" 。这将打开工作流编辑器，并产生一个.yaml文件，它保存在仓库的.github/workflows目录下。
创建GitHub Action工作流
保存后，工作流会检查我们仓库的代码，并运行一些echo命令。name用于以后跟踪状态和结果。run包含你要在每个步骤中运行的shell命令。
定义部署触发器
理论上讲，主分支(main branch)的每一次提交都应是可以提交到生产服务器(production server)的。然而，现实情况下，部署后我们也需要在生产服务器上进行测试，我们需要安排好部署时间。不同的公司有不同的部署时间，但往往大家只在工作日部署，周五除外。而且只能在下午4:00之前部署，以确保我们有时间在工作时间回滚(roll back)或修复问题。
获得手动级别控制的一个简单方法是建立一个分支(branch)，专门用于触发部署。这样一来，只要你准备好了，就可以专门将你的主分支合并到其中。将该分支称为生产分支(production branch)。
git push origin master:production
下面是我们如何将触发器改为只在推送到该生产分支时运行。
name: Deployment
on:
push:
branches: [ production ]
构建WordPress主题
如果我们使用WordPress Starter Theme Flynt，它本身就有Composer和npm的依赖管理，以及一个预先配置好的构建过程。如果我们重新开发一个主题，构建过程也非常相似，仅需要一些微小调整。而如果我们是将构建好的主题checkout到你的仓库中，我们可以跳过所有的步骤，除了checkout命令。
对于我们的例子，我们需要确保node是在所需的版本中执行的，并且在构建之前安装了依赖关系。
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v1.1.0
with:
version: 12.x
- name: Install dependencies
run: |
composer install -o
npm install
- name: Build
run: npm run build
配置服务器权限
为了成功运行rsync命令，GitHub需要访问SSH进入你的服务器。这可以通过以下方式实现:
-生成一个新的SSH密钥（不含口令）。
-将公钥添加到生产服务器上的~/.ssh/authorized_keys中。
-将私钥以 DEPLOY_KEY 的名字添加到存储库中。
GitHub配置服务器权限
同步工作流步骤需要将密钥保存到本地文件，调整文件权限，并将文件传给rsync命令。目标必须指向我们在生产服务器上的WordPress主题目录。我们可以将它定义为一个变量，这样当我们在未来的项目中重复使用工作流时，我们可以轻易地修改这个变量。
- name: Sync
env:
dest: 'ssh-user@example.com:/mydir/wp-content/themes/mytheme'
run: |
echo "${{secrets.DEPLOY_KEY}}" > deploy_key
chmod 600 ./deploy_key
rsync -chav --delete \
-e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' \
--exclude /deploy_key \
--exclude /.git/ \
--exclude /.github/ \
--exclude /node_modules/ \
./ ${{env.dest}}
根据我们的项目结构，我们可能想把插件和其他主题相关的文件也部署进去。为了实现这个目标，将源和目标修改为所需的父目录，确保检查排除的文件是否需要更新，并检查是否需要调整构建过程中的任何路径。
总结
完整的工作流程文件如下：
name: Deployment
on:
push:
branches: [ production ]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v1.1.0
with:
version: 12.x
- name: Install dependencies
run: |
composer install -o
npm install
- name: Build
run: npm run build
- name: Sync
env:
dest: 'ssh-user@example.com:/mydir/wp-content/themes/mytheme'
run: |
echo "${{secrets.DEPLOY_KEY}}" > deploy_key
chmod 600 ./deploy_key
rsync -chav --delete \
-e 'ssh -i ./deploy_key -o StrictHostKeyChecking=no' \
--exclude /deploy_key \
--exclude /.git/ \
--exclude /.github/ \
--exclude /node_modules/ \
./ ${{env.dest}}
测试工作流，提交更改，将其拉入本地仓库，并通过将主分支推送到生产分支来触发部署：
git push origin master:production
我们可以通过进入GitHub中的 "Action" 选项卡，然后选择最近执行的工作，点击 "部署" 工作，来跟踪执行状态。绿色的复选标记表示一切顺利。如果有任何问题，请检查失败步骤的日志来修复它们。
GitHub持续部署流程的设置
这样，我们的持续部署流程就设置完成了。
--阅读更多文章，请关注我的公众号：未定义变量
网友评论