WordPressの手動アップロードをやめて、GitHub Actions＋rsyncで自動デプロイにした話

Xserverなどの共用ホスティングでWordPressを個人運用していて、ファイルマネージャーでの手動アップロードに疲れているなら、GitHub Actions + rsync over SSHで「テーマフォルダだけ」を自動デプロイする構成がおすすめです。DB・アップロード画像・wp-config.phpは同期対象から外せるので、本番を壊すリスクを抑えたまま自動化できます。今回はこの構成を選ぶまでに比較した方法と、判断理由をまとめてみます。

背景: ファイルマネージャーでの手動更新がつらい
デプロイ対象を「テーマフォルダだけ」に絞った理由
rsyncを選んだ理由、他の方法を採用しなかった理由
実際の構成
やってみてどうだったか
まとめ
よくある質問
おすすめ記事

背景: ファイルマネージャーでの手動更新がつらい

子テーマのCSSやPHPを1行直すだけでも、Xserverのファイルマネージャーにログインして該当ファイルを探し、アップロードして上書き、を毎回繰り返してたんですよね。変更履歴は残らないし、「さっきの修正、どのファイルだったっけ」ってなることもしばしば。ヒューマンエラーで関係ないファイルを上書きしちゃうリスクもあるし、まぁそろそろ限界かなと。

最近は個人開発・個人ブログでもGitHub Actionsを使ったCI/CDが当たり前になってきてるので、これをWordPressの運用にも応用できないか考えてみました。

デプロイ対象を「テーマフォルダだけ」に絞った理由

最初に決めたのは、デプロイ対象の範囲です。WordPress本体・プラグイン・DB・アップロード画像・wp-config.phpまで全部同期する方法もありますが、今回はあえて自分が編集する子テーマフォルダ(wp-content/themes/配下)だけに絞りました。

理由は大きく2つあります。

wp-config.phpにはDB接続情報など環境ごとに異なる値が入っているため、ローカルの設定で本番を上書きする事故を防ぎたかった
プラグインはwp-admin側で自動更新されることがあるので、デプロイで毎回上書き・巻き戻ししてしまうと管理が二重になる

なお、git管理の範囲とデプロイ(本番反映)の範囲は別物として扱っています。git管理はWordPress本体やプラグインも含めたプロジェクト全体にしていて、これは将来Docker環境ごと再現できるようにするためです。一方でデプロイは子テーマのみ。「gitに入れているもの」と「本番に自動で送るもの」を意図的に分けたのがポイントです。

rsyncを選んだ理由、他の方法を採用しなかった理由

デプロイの仕組み自体も、3つの方法を比較してから決めました。

GitHub Actions + rsync over SSH(採用)
GitHub Actions + FTP/SFTPデプロイ用アクション
サーバー側でgit pullする方式

XserverではすでにSSHが有効になっていたので、わざわざ別プロトコルのFTP/SFTPを使うメリットは薄いと判断しました。速度面でも、除外設定の柔軟さでも、SSHが使える状況ならrsyncの方が素直です。

サーバー側でgit pullする方式は、公開ディレクトリ自体が.gitを含むワーキングツリーになってしまう点が引っかかりました。.htaccessで.gitへのアクセスを拒否する設定などが追加で必要になり、個人運用にはやや過剰だと感じたので見送っています。

実際の構成

採用したのは、easingthemes/ssh-deployというGitHub Actionを使う構成です。設定がシンプルで、rsyncのラッパーとして必要な項目(同期元・同期先・SSH接続情報)を指定するだけで動きます。

ワークフローの骨格はこんな感じです(実際のホスト名やパスはGitHub Secretsとして管理しています)。

on:
  push:
    branches: [main]
  workflow_dispatch:
    inputs:
      dry_run:
        type: boolean
        default: false

mainブランチへのpush(プルリクエストのマージも含む)をトリガーに、public_html/wp-content/themes/cocoon-child-master/だけをXserver側の同じパスへrsync -avzr --deleteで反映します。同期範囲をテーマフォルダだけに絞っているので、--excludeを個別に書かなくてもwp-config.phpやアップロード画像はそもそも対象外になります。

必要なGitHub Secretsは以下の5つです。

DEPLOY_SSH_PRIVATE_KEY
DEPLOY_HOST
DEPLOY_USER
DEPLOY_PORT(Xserverは標準の22ではない場合があるので、契約しているサーバーパネルの「SSH設定」で確認してください)
DEPLOY_PATH

初回はworkflow_dispatchでの手動実行にdry_runフラグを用意し、-avzrn(rsyncのドライランオプション)で差分だけ確認してから、実際のpushトリガーに切り替えました。いきなり本番に向けて実行するのはちょっと怖かったので、この一手間は入れておいてよかったなと思います。

やってみてどうだったか

導入後は、git pushするだけでテーマの変更が本番に反映されるようになりました。ファイルマネージャーを開く手間も、どのファイルを上げ忘れたか不安になることもなくなって、地味に快適です。DB・画像・wp-config.phpが同期対象外なのも設計通りで、これまで事故は起きていません。

個人開発のため、デプロイ失敗時のSlack通知などはまだ導入していません。今のところはGitHub Actionsの実行結果が赤くなっていれば気づける規模なので、必要になったら追加する想定です。

まとめ

WordPressの本番デプロイを自動化するなら、「全部同期する」のではなく「自分が編集する範囲だけ同期する」という設計にすると、DBや画像を巻き込む事故を構造的に避けられるかなと思います。SSHが既に使えるホスティングであれば、GitHub Actions + rsyncはFTPデプロイやサーバー側git pull方式よりシンプルに組めるはずです。

よくある質問

プラグインの自動更新とデプロイがぶつかることはない？

デプロイ対象を子テーマフォルダのみに絞っているので、プラグイン本体は同期対象外です。ぶつかりません。

Xserver以外の共用ホスティングでも同じ方法でできる？

SSHでのrsync接続が許可されているホスティングであれば、基本的な考え方は応用できると思います。ただしSSHのポート番号や接続仕様はサービスごとに異なるので、契約しているサーバーの管理画面で確認してください。

デプロイに失敗したらどうなる？

rsyncのステップが失敗するとGitHub Actionsのワークフロー自体が失敗(赤)になります。個人開発の規模であれば、その表示を見て気づく運用で今のところ十分でした。

wp-config.phpはどうやって本番側に置いている？

本番側のwp-config.phpはそのまま残し、デプロイの同期対象から外しています。ローカルと本番でDB接続情報などが異なるため、上書きされないようにする設計です。