DeployerでWordPressをデプロイする設定方法（インストールからロールバックまで）

Deployer は PHP 製のデプロイツールで、deploy.php に接続先と共有ファイルを書いておけば、dep deploy の1コマンドでサーバーへの配置と公開の切り替えを行い、不具合が出たら dep rollback で前のリリースに戻せます。この記事では、Composer での導入から、WordPress 向けの deploy.php の書き方、wp-config.php と uploads の共有設定、WP-CLI を組み込んだ後処理、つまずきやすい点までを説明します。

Deployer のしくみ：releases と current

Deployer は、デプロイのたびにサーバー上へ新しいディレクトリ（リリース）を作り、準備が終わった時点で current というシンボリックリンクを新しいリリースに付け替えます。サーバー上の構成はおおむね次のようになります。

/var/www/example.com/          ← deploy_path
├── current -> releases/5      ← Webサーバーの公開ディレクトリはここを指す
├── releases/
│   ├── 3/
│   ├── 4/
│   └── 5/
└── shared/                    ← リリースをまたいで共有するもの
    ├── wp-config.php
    └── wp-content/uploads/

ファイルの転送中は古いリリースが公開されたままなので、上書き中に中途半端な状態が見えることがありません。前のリリースもサーバーに残っているため、切り戻しはシンボリックリンクを戻すだけで済みます。

一方、wp-config.php やアップロード画像のように、リリースごとに作り直してはいけないものは shared/ に置き、各リリースからシンボリックリンクで参照させます。WordPress で Deployer を使うときは、この共有設定が一番のポイントです。

前提と準備

• 手元（またはCI）に PHP と Composer があること
• サーバーに SSH 鍵で接続でき、サーバー側から Git リポジトリを取得できること（デプロイキーなどを設定）
• WordPress のコード（本体を含めるか、テーマ・プラグインだけにするかは構成次第）が Git で管理され、wp-config.php と uploads はリポジトリに含まれていないこと

この記事のコードは Deployer 7 系の書き方です（2026年10月現在）。Deployer はメジャーバージョンで設定の書き方が変わっているため、使うバージョンのドキュメントで構文を確認してください。

既存のサイトを Deployer 方式に移す場合は、作業前に wp db export でデータベースを書き出し、ファイル一式のバックアップも取っておきます。最初はステージングサーバーで構成を作り、動作を確かめてから本番に適用します。

Deployer をインストールする

プロジェクトの開発用依存として Composer で入れます。

composer require --dev deployer/deployer
vendor/bin/dep --version

続けて dep init を実行すると、対話形式で質問に答えながら設定ファイルの雛形を作れます。

vendor/bin/dep init

途中でプロジェクトの種類（レシピ）を選ぶ項目があります。Deployer には WordPress 用のレシピ（recipe/wordpress.php）が用意されているので、一覧に WordPress があればそれを選びます。収録されているレシピは Deployer のバージョンによって異なるため、選択肢やドキュメントのレシピ一覧で確認してください。設定ファイルは PHP 形式（deploy.php）と YAML 形式を選べますが、この記事では処理を追加しやすい deploy.php を使います。

deploy.php の基本設定

WordPress 向けの最小限の設定例です。値は自分の環境に合わせて書き換えます。

<?php
namespace Deployer;

require 'recipe/wordpress.php';

// 取得元のリポジトリ
set('repository', 'git@github.com:your-org/your-site.git');

// サーバーに残すリリースの数
set('keep_releases', 5);

// リリースをまたいで共有するファイルとディレクトリ
add('shared_files', ['wp-config.php']);
add('shared_dirs', ['wp-content/uploads']);
add('writable_dirs', ['wp-content/uploads']);

// 接続先
host('production')
    ->set('hostname', 'example.com')
    ->set('remote_user', 'deploy')
    ->set('deploy_path', '/var/www/example.com')
    ->set('branch', 'main');

host('staging')
    ->set('hostname', 'staging.example.com')
    ->set('remote_user', 'deploy')
    ->set('deploy_path', '/var/www/staging.example.com')
    ->set('branch', 'develop');

after('deploy:failed', 'deploy:unlock');

WordPress のレシピにはすでに wp-config.php と uploads の共有設定が含まれている場合があります。add() は既存の配列に値を追加する関数なので、重複しても動作上の問題になりにくい書き方ですが、レシピの中身を一度開いて、何が既定で設定されているかを確認しておくと安心です。

keep_releases を大きくしすぎると、リリースごとにファイル一式が残るためディスクを圧迫します。切り戻しに使うのは直近のいくつかなので、3〜5程度から始めると扱いやすいでしょう。

初回デプロイ前に shared を用意する

共有ファイルが shared/ に存在しない場合、Deployer は空のファイルを用意して先へ進むことがあります。空の wp-config.php が参照されるとサイトは表示できなくなるため、初回のデプロイ前にサーバー上で本物の wp-config.php と uploads を配置しておきます。

# サーバー上で（既存サイトから移す例）
mkdir -p /var/www/example.com/shared/wp-content
cp /var/www/old-site/wp-config.php /var/www/example.com/shared/wp-config.php
cp -a /var/www/old-site/wp-content/uploads /var/www/example.com/shared/wp-content/

wp-config.php にはデータベースのパスワードが含まれます。ファイルの権限を必要最小限にし、リポジトリには入れないでください。

デプロイを実行する

# まずステージングへ
vendor/bin/dep deploy staging

# 問題がなければ本番へ
vendor/bin/dep deploy production

どのタスクがどの順で動くかを知りたいときは vendor/bin/dep list でタスクの一覧を表示できます。失敗したときは -v、-vv、-vvv を付けると出力が詳しくなり、どのコマンドで止まったかを追えます。

Webサーバーの公開ディレクトリ

Webサーバーの公開ディレクトリ（Nginx の root や Apache の DocumentRoot）は、deploy_path ではなく current を指すように設定します。

root /var/www/example.com/current;

PHP-FPM と OPcache を使っている環境では、シンボリックリンクを切り替えても古いリリースのファイルがキャッシュから実行され続けることがあります。Nginx では fastcgi_param SCRIPT_FILENAME と DOCUMENT_ROOT に $realpath_root を使う設定がよく使われるほか、デプロイ後に PHP-FPM をリロードする方法もあります。環境に合わせていずれかを採用してください。

WP-CLI の処理をデプロイに組み込む

Deployer では独自のタスクを定義し、既存のタスクの前後に差し込めます。デプロイ前のデータベースバックアップと、公開後のデータベース更新・キャッシュ削除を WP-CLI で行う例です。サーバーに WP-CLI がインストールされている前提です。

// 現在公開中のリリースがあれば、切り替え前にDBを書き出す
task('wp:backup', function () {
    if (test('[ -L {{current_path}} ]')) {
        run('mkdir -p {{deploy_path}}/backups');
        run('cd {{current_path}} && wp db export {{deploy_path}}/backups/pre-deploy-$(date +%Y%m%d%H%M%S).sql');
    }
});

// 公開後の後処理
task('wp:after-deploy', function () {
    run('cd {{current_path}} && wp core update-db && wp cache flush');
});

before('deploy:symlink', 'wp:backup');
after('deploy:symlink', 'wp:after-deploy');

初回のデプロイでは current がまだ存在しないため、test() でシンボリックリンクの有無を確かめてからバックアップしています。backups ディレクトリは公開ディレクトリの外にあるので、Web から直接ダウンロードされる心配がありません。古いバックアップは容量を圧迫するため、定期的に整理します。

テーマやプラグインの依存関係を Composer で管理している場合は、コード取得後に Composer を実行するタスク（deploy:vendors）を組み込む方法があります。WordPress のレシピの既定の流れに含まれているかはバージョンによって異なるため、dep list やレシピの中身で確認してから追加してください。

不具合が出たら dep rollback

公開後に問題が見つかった場合は、ひとつ前のリリースに戻せます。

vendor/bin/dep rollback production

current のリンク先が前のリリースに戻るだけなので、短時間で切り戻せます。ただし、戻るのはファイルだけで、データベースは戻りません。wp core update-db やプラグインの更新でデータベースの構造が変わっていた場合は、wp:backup で書き出したファイルを wp db import で戻す判断が必要になります。バックアップ以降の注文やコメントも失われるため、データベースの復元は影響を確認してから行ってください。

つまずきやすいポイント

• デプロイが途中で止まり、次から「ロックされている」と出る：前回のデプロイが異常終了するとロックが残ることがあります。vendor/bin/dep deploy:unlock production で解除します。他の人がデプロイ中でないことを確認してから実行してください。
• サーバーから Git を取得できない：Deployer はサーバー側でリポジトリを取得します。サーバーのユーザーにデプロイキーを登録するか、SSH エージェントの転送を設定します。
• uploads の画像が表示されない：shared_dirs の指定漏れや、初回に shared/ へ既存の画像を移し忘れていることがよくある原因です。リリース内の wp-content/uploads が shared/ へのシンボリックリンクになっているかを確認します。
• 書き込み権限のエラー：writable_dirs の設定と、PHP の実行ユーザー（www-data など）とデプロイユーザーの関係を確認します。

まとめ

• Deployer はリリースごとにディレクトリを作り、current のシンボリックリンクを切り替えて公開する
• composer require --dev deployer/deployer で導入し、dep init で雛形を作る。WordPress のレシピはバージョンごとの収録状況を確認する
• wp-config.php は shared_files、uploads は shared_dirs に指定し、初回デプロイ前にサーバーの shared/ へ配置しておく
• before / after でタスクを差し込み、切り替え前に wp db export、公開後に wp core update-db と wp cache flush を実行する
• 切り戻しは dep rollback。データベースは戻らないので、バックアップからの復元手順も決めておく

• WordPressをゼロダウンタイムでデプロイする方法
• WP-CLIでCI/CDパイプラインを構築する方法