WordPressの各環境（本番・ステージング・開発）間でデータベースのスキーマ変更を管理するのはミスが起こりやすく、時間もかかります。SQLクエリを1つ間違えたり、必要なデータベース変更を適用し忘れたりするだけで、デプロイ時にサイトが正常に動作しなくなることも。さらに、SQLスクリプトを手動で実行したり、データベースを直接編集したりする方法では、バージョン管理や監査ログ（変更履歴）の記録ができず、環境間での整合性を保つのも難しくなります。
こうした課題を解決してくれるのが、RootsのRadicle（特にAcorn）です。Radicleを導入することで、Laravelのマイグレーション機能をWordPressでも利用できるようになります。コードと一緒にバージョン管理されたデータベース変更をデプロイできるほか、どの変更が適用済みかを自動で追跡し、必要に応じてスキーマ変更をロールバックすることも可能です。
さらに、これをKinstaのインフラと各種ツールと組み合わせることで、デプロイ時にマイグレーションを自動実行する仕組みを構築することができます。
WordPressデータベースの変更にバージョン管理が必要な理由
データベースを手動で変更する運用では、スキーマ変更が「バージョン管理されたコード」ではなく、その場限りの作業として扱われがちです。たとえば、カスタムテーブルを追加するためにSQLクエリを実行したり、ALTER TABLE文でカラムを追加したり、あるいはプラグインの有効化フックに更新処理を任せたりするケースが挙げられます。これらの方法は最初は問題なく動作することもありますが、複数の環境を運用している場合や、チームで開発している場合には破綻しやすくなります。
特にステージング環境は、ローカル環境で行った小さな変更（ローカルのデータベースにカラムを追加したなど）を記録し忘れると、徐々に差分が生まれていきます。その結果、本番環境へのデプロイ時に不整合が発生し、デプロイが失敗する原因となります。また、このような運用では変更履歴（監査ログ）を残しにくい点も課題です。
こうした環境間のズレや連携ミスを防ぐ方法として有効なのが、Laravelのマイグレーションです。マイグレーションは、データベース変更をGitリポジトリ内の「バージョン管理されたコード」として扱います。これにより、アプリケーションとともにデプロイされ、すべての環境で同じ順序で確実に実行されます。
Acornを使ってWordPressでLaravelマイグレーションを利用する仕組み
Laravelのマイグレーションは、データベースのスキーマ変更を定義するPHPファイルです。各マイグレーションには2つのメソッドがあり、up()で変更を適用し、down() で変更を元に戻します。マイグレーションファイルにはタイムスタンプの接頭辞が付与されており、これによって実行順序が決まります。RootsのAcornを利用すると、Laravelを完全にインストールしなくても、WordPress上でこのマイグレーションシステム（およびその他の機能）を利用できます。
マイグレーションシステムは、WordPressデータベース内のmigrationsテーブルを使用して、どの変更が実行済みかを管理します。wp acorn migrateを実行すると、Acornは以下の処理を行います。
-
テーブルを確認し、未実行のマイグレーションを特定
-
タイムスタンプに基づき、時系列順にマイグレーションを実行
-
実行が成功したマイグレーションを記録
この仕組みにより、マイグレーションが重複して実行されることを防ぎつつ、どの環境にどのスキーマ変更が適用されているかを明確に把握できます。
また、AcornはLaravelのSchema Builderとも統合されており、データベーステーブルの作成・変更を、読みやすいPHP構文で記述できます。生のSQLを書く代わりに、たとえば $table->string('key')->unique()や$table->json('value')->nullable()のようなメソッドを使用します。この方法は、データベースに依存しにくい記述ができるほか、型の安全性を高められ、文字列を連結したSQLよりも可読性の高いコードになります。
最初のマイグレーションの作成と実行
WP-CLIを使ってマイグレーションを作成します。
wp acorn make:migration create_app_settings_tabledatabase/migrations/ディレクトリに現在のタイムスタンプと指定した名前でマイグレーションファイルを生成します。
<?php use IlluminateDatabaseMigrationsMigration; use IlluminateDatabaseSchemaBlueprint; use IlluminateSupportFacadesSchema; 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:rollback コマンドを使用します。このコマンドは、直近のバッチに含まれる各マイグレーションに対してdown()を実行し、変更を取り消します。
データベーススタジオを使ったマイグレーションの検証
マイグレーションを実行した後は、Kinstaのデータベーススタジオ（または他のデータベースツール）を使用して、想定どおりのテーブルやカラムが正しい構造で作成されているかを確認できます。データベーススタジオにアクセスするには、MyKinstaから任意のサイトを開き、「データベース」をクリックします。
付属のSQLコンソールでは、検証用クエリを実行し、マイグレーションによって期待どおりの構造が作成されているかをチェックできます。
たとえば、app_settingsテーブルを作成した後にDESCRIBE app_settings;を実行すると、カラム名、データ型、インデックスなどを含むテーブル構造が表示されます。さらに、SELECT * FROM app_settings;を実行すれば、テーブルがデータを正しく受け付けるかをテストできます。
また、フィルタリング機能を使えば、SQLを記述せずに特定のレコードやカラムを確認可能です。カラム見出しをクリックして並び替えたり、フィルターを適用して結果を絞り込んだり、データをエクスポートしたりできます。
これらのエクスポートオプションはロールバック手順をテストする前に便利です。
KinstaでSSHとWP-CLIを使ってマイグレーションを実行する
Kinstaでは、すべてのプランでSSHアクセスとWP-CLIをサポートしているため、設定なしでステージング環境および本番環境でマイグレーションコマンドを直接実行できます。
Kinstaの環境でマイグレーションを実行するには、まずSSHで対象環境に接続します。接続に必要な認証情報は、MyKinstaの各サイトの「情報」画面で確認可能です。
接続および認証が完了したら、サイトのドキュメントルートに移動します。Radicleサイトの場合は、publicディレクトリがこれに当たります。次に、wp acorn migrateを実行します。
マイグレーションの実行中は、どのマイグレーションが処理されているか、および各マイグレーションの完了状況が出力として表示されます。また、Acornは各環境のデータベース内でマイグレーションの実行状況を個別に管理するため、この手順はステージング環境および本番環境のいずれでも同様に利用できます。
Kinstaステージング環境でのマイグレーションのテスト
Kinstaのステージング環境は、本番環境へデプロイする前にマイグレーションを安全にテストできる場になりますが、検証を行うには適切なワークフローを整えておく必要があります。データベーススタジオでマイグレーションによる変更を確認したら、次にロールバックのテストを行い、down()が正しく動作することも確認してください。
ロールバックを検証するには、MyKinstaでステージング環境に切り替え、「データベース」に移動し、マイグレーションによって作成または変更されたテーブルを確認します。
ステージング環境でのテスト中に問題が見つかった場合は、wp acorn migrate:rollbackコマンドを使用することで、直近のバッチのマイグレーションを元に戻し、本番環境に影響を与えることなく修正できます。その後、マイグレーションファイルを編集して変更をコミットし、再度ステージング環境へデプロイしてテストをやり直します。
選択的プッシュ機能を使うと、テスト済みの変更のみを本番環境へ反映することができます。たとえば、ファイルのみを本番環境へプッシュすることも、ファイルとデータベースの両方をプッシュすることも可能です。
マイグレーションのワークフローでは、マイグレーションがステージング環境のデータで本番データベースを上書きするのではなく、既存の本番データベースに対して実行されるため、通常はファイルのみを反映します。
マイグレーションを自動実行するデプロイワークフロー
マイグレーションを自動化したワークフローでは、コードのデプロイと同時にデータベーススキーマの変更が実行されます。これにより手動作業を省略でき、デプロイ時のミスも減らせます。自動化を実現するには、SSHによる手動スクリプト、GitHub Actionsによる自動化、またはRootsのTrellisなどのツールを利用し、デプロイプロセスにマイグレーションコマンドを組み込みます。
SSHを使用して手動でデプロイする場合は、本番環境に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リポジトリに含まれるため、マイグレーションはコードとともにバージョン管理され、開発からデプロイまで一貫して扱うことができます。ワークフローも一般的な開発手順と同様で、ローカル環境でマイグレーションを作成し、機能ブランチにコミットしたうえで、テスト後に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
{
// このマイグレーションはデータを削除するため、元に戻すことはできません
Log::warning("Migration cannot be reversed - data permanently deleted");
}このような制約は、あらかじめ文書化しておくことが重要です。Kinstaの自動バックアップは安全策として有効ですが、問題が発生する可能性のあるマイグレーションを実行する前には、手動バックアップも作成しておくことをおすすめします。
対象のサイトを開き、「バックアップ」をクリックして、内容が分かる名前を付けてバックアップを作成してください。万が一、本番環境でマイグレーションにより想定外の問題が発生した場合は、MyKinstaからこのバックアップを使用して復元できます。
マイグレーションのロールバックを行う際は、本番環境に対してデータベースのみを復元します。復元は数分以内に完了し、バックアップ作成時点の状態にデータベースを正確に戻すことができます。
WordPressのための信頼性の高いデータベース運用を構築
RadicleのAcorn実装を通じてLaravelマイグレーションを導入することで、これまで不安要素になりやすかったデータベース変更を、予測可能でバージョン管理されたプロセスへと変えることができます。「マイグレーション＝コード」という考え方に、Kinstaのステージング環境と、Database Studioによる検証を組み合わせることで、スキーマの問題を本番環境へ反映する前に検知できるワークフローが実現します。
このように、RadicleやAcornといったツールを取り入れた最新のWordPress開発では、WordPressのエコシステムと、プロフェッショナルな開発ツール／フレームワークのどちらかを選ぶ必要はありません。これは、Acornを通じたLaravelのキュー、Bladeテンプレート、カスタムWP-CLIコマンドにも同じことが言えます。
ワークフローを導入する準備が整ったら、次はマイグレーションの運用ルールを定めてみてください。たとえば、マイグレーションファイルの命名規則、手順の文書化、主要なマージ前に求めるテスト要件の策定など。KinstaのWordPress専用マネージドクラウドサーバーは、SSHアクセス、ステージング環境、データベーススタジオなどの開発者向けツールを標準提供し、RadicleおよびAcornマイグレーションを含む最新のワークフローを支援しています。
