在 WordPress 环境中管理数据库架构变更通常是一项容易出错且耗时的任务。单个放错位置的 SQL 查询或忘记的数据库修改在部署期间就会导致网站崩溃。此外，手动 SQL 脚本和直接编辑等操作缺乏版本控制、审计跟踪和跨环境协调能力。
使用 Roots 的 Radicle（具体是 Acorn）是一种解决方案，因为它将 Laravel 迁移带入 WordPress。你可以获得随代码一起部署的版本控制数据库变更、自动跟踪已运行的变更，以及在需要时回滚架构修改的能力。
当你将此与 Kinsta 的基础设施和工具结合使用时，你就获得了一种在部署期间自动执行迁移的方法。
为什么 WordPress 数据库变更需要版本控制
手动数据库修改将架构变更视为一次性操作，而不是版本化代码。例如，你运行 SQL 查询 添加自定义表，执行 ALTER TABLE 语句添加列，或依靠插件激活钩子来处理更新。这些解决方案最初可以工作，但在管理多个环境或团队协作时会失效。
一旦你忘记记录较小的变更（例如向本地数据库添加列），暂存环境就开始与本地环境分离，这也会导致生产部署失败。这也意味着缺乏审计跟踪。
Laravel 迁移 是消除这些协调失败的好方法，因为它们将数据库变更视为存放在 Git 仓库中的版本化代码。这会随你的应用程序一起部署，并在每个环境中按相同顺序执行。
Acorn 如何在 WordPress 中使用 Laravel 迁移
Laravel 迁移是 PHP 文件，通过两种方法定义数据库架构变更：up() 应用变更，down() 回滚变更。每个迁移文件都有时间戳前缀，用于确定执行顺序。Roots 的 Acorn 将此迁移系统（以及更多功能）带入 WordPress，无需安装完整的 Laravel。
迁移系统使用 WordPress 数据库中的 migrations 表跟踪已运行的变更。当你执行 wp acorn migrate 时，Acorn 会执行以下任务：
- 检查表以识别待处理的迁移。
- 根据时间戳按时间顺序运行表。
- 记录每个成功的迁移。
此跟踪防止迁移多次运行，并向你显示已应用于任何环境的架构变更。
Acorn 集成了 Laravel 的架构构建器，提供了流畅的 PHP 语法来创建和修改数据库表。你无需编写原始 SQL，而是使用诸如 $table->string('key')->unique() 或 $table->json('value')->nullable() 之类的方法。这种方法提供与数据库无关的语法、类型安全性，以及比带连接字符串的 SQL 语句更具可读性的代码。
创建和运行你的第一个迁移
你可以通过 WP-CLI 创建迁移：
wp acorn make:migration create_app_settings_table
这将在 database/migrations/ 目录中生成一个新的迁移文件，包含当前时间戳和你指定的名称：
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
return new class extends Migration { public function up(): void { Schema::create('app_settings', function (Blueprint $table) { $table->id(); $table->string('key')->unique(); $table->json('value')->nullable(); $table->string('group')->default('general'); $table->boolean('is_public')->default(false); $table->text('description')->nullable(); $table->timestamps(); $table->index('group'); $table->index('is_public'); }); }
public function down(): void
{
Schema::dropIfExists('app_settings');
}};
`up()` 方法创建表，包含用于存储键值对、分组设置以及跟踪条目创建或修改时间的列。`group` 和 `is_public` 上的索引提高了查询性能。`down()` 方法完全删除表，这样你可以撤销迁移。
你可以使用 `wp acorn migrate` 命令执行待处理的迁移。这会运行所有尚未执行的迁移，创建表并修改数据库架构。你可以使用 `wp acorn migrate:status` 命令检查哪些迁移已经运行。状态输出显示每个迁移文件及其是否已运行的标识。
当需要撤销上一批迁移时，使用 `wp acorn migrate:rollack` 命令。这会执行上一批中每个迁移的 `down()` 方法来撤销更改。
## 使用 Database Studio 验证迁移
运行迁移后，[Kinsta 的 Database Studio](https://kinsta.com/docs/wordpress-hosting/database-management/wordpress-database-studio/)（或任何其他数据库工具）可以让你验证预期的表和列是否以正确的结构存在。你可以通过 MyKinsta 仪表板访问 Database Studio，方法是导航到任意站点并点击 **Database** 选项卡：
*Database Studio 界面，显示 WordPress 数据库表列表。*
内置的 SQL 控制台允许你运行验证查询，以确认你的迁移已创建预期的结构。
创建 `app_settings` 表后，可以使用 `DESCRIBE app_settings;` 查询来验证列。这将返回表结构，显示列名、类型和索引。另一个查询 `SELECT * FROM app_settings;` 可以测试表是否接受插入操作。
通过筛选功能，你可以检查特定的记录或列，而无需编写 SQL 查询。在这里，你可以点击列标题进行排序、应用筛选器来缩小结果范围，并导出数据：
*Database Studio 实例显示在数据库表上设置的筛选器。*
这些导出选项在测试回滚程序之前很有用。
## 在 Kinsta 上通过 SSH 和 WP-CLI 运行迁移
Kinsta 在所有套餐中都包含 SSH 访问和 WP-CLI。这意味着你可以在 staging 和生产环境中直接运行迁移命令，无需任何额外设置。
要在 Kinsta 环境中运行迁移，首先[使用 SSH 连接](https://kinsta.com/docs/wordpress-hosting/connect-to-ssh/)到它。凭据位于 MyKinsta 中任意站点的 **Info** 屏幕上：
*在 MyKinsta 仪表板中查找 SSH 凭据。*
连接并通过身份验证后，导航到您站点的文档根目录。对于 Radicle 站点，这是 `public` 目录。接下来，执行 `wp acorn migrate`。
迁移过程会显示正在运行的迁移以及每个迁移的完成状态。这同样适用于[暂存和生产环境](https://kinsta.com/docs/wordpress-hosting/staging-environment/)，因为 Acorn 会在每个环境的数据库中独立跟踪迁移。
### 在 Kinsta 暂存环境中测试迁移
*MyKinsta 环境屏幕，显示创建新暂存环境的选项。*
[Kinsta 的暂存环境](https://kinsta.com/blog/kinstas-staging-environments/)是在部署到生产环境之前测试迁移的安全空间，但您需要一个可靠的工作流程来测试它们。在数据库工作室中验证迁移更改后，查看测试回滚以确保 `down()` 方法正常工作。
为此，请在 MyKinsta 中切换到您的暂存环境，导航到 **Database** 选项卡，检查您的迁移创建或修改的表。
如果在暂存测试中发现问题，`wp acorn migrate:rollback` 命令可让您回滚上一批迁移并进行修改，而不会影响生产环境。然后您可以修改迁移文件，提交更改，再次部署到暂存环境，然后重新测试。
Kinsta 的选择性推送让您可以只部署经过测试的更改，因此您可以选择仅将文件推送到生产环境，或者同时推送文件和数据库：
*MyKinsta 推送到正式环境界面。*
对于迁移工作流程，您通常只推送文件，因为迁移是在现有生产数据库上运行，而不是用暂存数据覆盖它。
## 包含自动化迁移的部署工作流程
自动化迁移工作流程会在代码部署时运行数据库架构更改，从而消除手动步骤并减少部署错误。您可以通过在部署流程中添加迁移命令来实现这一点，无论是手动 SSH 脚本、[GitHub Actions](https://kinsta.com/blog/github-actions/) 自动化，还是 Roots 的 [Trellis](https://kinsta.com/blog/bedrock-trellis/) 等工具。
对于使用 SSH 的手动部署，请连接到您的生产环境并导航到文档根目录。接下来，按顺序运行以下命令：
git pull origin main composer install –no-dev npm install && npm run build wp acorn optimize wp acorn migrate –force
`--force` 标志告诉 Acorn 无需确认提示即可运行迁移，这对于自动化部署至关重要，因为在自动化部署中您无法与终端交互。在 `wp acorn optimize` 之后运行此命令可确保应用程序缓存在迁移运行之前是新鲜的。
如果您使用 GitHub Actions 进行持续部署，您可以在工作流程文件中自动化迁移。Radicle 包含一个 `.github/workflows/deploy.yml` 配置，您可以修改它以在构建过程之后包含一个迁移步骤：
- name: Run migrations run: | ssh user@host -p port 'cd /path/to/site && wp acorn migrate –force'
部署工作流程通过 SSH 连接，导航到您的站点目录，然后运行迁移命令。
对于使用 Trellis 的部署，迁移会集成到部署钩子中。您可以通过修改 `deploy-hooks/finalize-after.yml` 来包含以下内容：
- name: Run Acorn migrations command: wp acorn migrate –force args: chdir: "{{ deploy_helper.new_release_path }}"
这是在 Trellis 完成其他部署任务后运行迁移。迁移会在新的发布目录中执行，如果部署失败，Trellis 会处理回滚。
### 使用 Git 对迁移文件进行版本控制
迁移文件位于 Radicle 项目结构中的 `database/migrations/` 目录中。该目录是您的 [Git 仓库](https://kinsta.com/docs/wordpress-hosting/site-management/git/) 的一部分，这意味着迁移会通过版本控制与您的代码一起传播。工作流程与标准开发类似：在本地创建迁移，将其提交到功能分支，测试后合并到 main 分支。
迁移的提交流程遵循一致的模式：
git add database/migrations/2025_01_03_140000_create_app_settings_table.php git commit -m "Add app_settings table migration" git push origin feature-branch
审查迁移后，您可以将功能分支合并到 `main`。这使得迁移可以用于预发布和生产部署。
`wp acorn migrate:status` 命令可验证所有环境是否应用了相同的迁移。您可以在所有环境中运行此命令以确认它们是否同步。如果某个环境显示有待处理的迁移，则表示它需要部署或手动运行迁移才能同步。
## 回滚策略和数据库备份
然而，并非所有迁移都可以完全撤销。虽然您可以通过简单地删除表来撤销其创建，但删除数据的迁移是永久性的。有时，`down()` 方法可以告诉您为什么无法回滚：
public function down(): void { // This migration cannot be reversed as we're deleting data \Log::warning("Migration cannot be reversed – data permanently deleted"); }
最好记录这些限制。Kinsta 的[自动备份](https://kinsta.com/docs/wordpress-hosting/wordpress-backups/#wordpress-backup)提供了安全网，因此在运行可能造成问题的迁移之前创建手动备份也很重要：
*MyKinsta 中的手动备份。*
导航到您的网站，点击**备份**，并使用描述性名称生成备份。如果迁移在生产环境中造成意外问题，您可以通过 MyKinsta 从此备份恢复。
对于迁移回滚，您只需将数据库恢复到生产环境。恢复会在几分钟内完成，并将您的数据库恢复到备份中捕获的确切状态。
## 为 WordPress 构建可靠的数据库工作流程
通过 [Radicle](https://roots.io/radicle/) 实现的 [Acorn](https://roots.io/acorn/) 的 Laravel 迁移将通常是焦虑根源的功能转变为可预测的、版本控制的过程。迁移即代码、Kinsta 的预发布环境以及用于验证的数据库工作室的组合创建了一个工作流程，让您在架构问题进入生产环境之前就能发现它们。
因此，包含 Radicle 和 Acorn 等工具的现代 WordPress 开发意味着您不必在 WordPress 的生态系统和专业工具框架之间做出选择。同样的模式也适用于 [Laravel 队列](https://roots.io/acorn/docs/creating-and-processing-laravel-queues/)、[Blade 模板](https://kinsta.com/blog/laravel-blade/)，以及通过 Acorn 的自定义 WP-CLI 命令。
如果您准备好采用此工作流程，下一步是建立迁移约定，例如定义迁移文件的命名模式、流程文档，以及在关键合并之前建立测试要求。 [Kinsta 的 WordPress 托管服务](https://kinsta.com/wordpress-hosting/) 提供内置开发者工具来帮助您（例如 SSH 访问、预发布环境和数据库工作室），以支持现代工作流程，包括 Radicle 和 Acorn 迁移。
