前回記事の続きです。

前回はWordPress本体のバージョン管理でしたが、バージョンアップはそれほど頻度は高くありません。また、プラグインも同様です。
一方、デザインにかかわるところの更新頻度は高くなりがちです。この2つを混ぜると管理上めんどうなことが起きやすくなりそうなので、分ける方法を考えます。

git subtreeを使う

このサイトで利用しているWordPressのテーマ、Simplicityを使うとします。このテーマは頻繁に改修を入れられているので、WordPress日本語版同様にzipからリポジトリ管理をするとします。

そして、git subtreeを使うことで、テーマのリポジトリを取り込みます。イメージとして、次のような管理体制を取ります。

zip展開リポジトリには直接手は加えません。真ん中のwp-packリポジトリでは各サイト共通で使うプラグインとテーマを展開します。simplicityに共通で手を入れる部分はここで手を入れます。そして各サイト向けリポジトリではそれぞれ独自に必要な手を入れます。

この構成でWordPressとSimplicityのそれぞれのバージョンアップがあっても、wp-packまたは各サイトで自動マージが可能になります。

管理サイト数が1つならwp-packをサイト向けリポジトリにしてしまってもいいと思います。また、Simplicityに手を入れないならwp-packに直接展開しても良いです。上図の構成はガッツリ組みすぎな感は否めないので、メリットを受けられる部分だけ切り分けて管理してもいいと思います。

subtreeの使い方

wp-content/themesにSimplicityを展開する

git subtree addで指定ディレクトリにsimplicityを展開します。あらかじめremoteでリポジトリを追加しておくとコマンドが短くなって楽です。

$ git remote add simplicity-zip git@gitlab.com:noldor/simplicity-zip.git
$ git fetch simplicity-zip
$ git subtree add --prefix wp-content/themes/simplicity simplicity-zip master --squash

wp-content/themes/simplicityのバージョンアップをする

simplicityリポジトリを更新したあと、git subtree pullを使います。

$ git subtree pull --prefix wp-content/themes/simplicity simplicity-zip master --squash

ここでコンフリクトが起きたら手動マージすることになります。

注意点

git subtreeを使う場合、subtree配下の修正とそれ以外の修正を混ぜたコミットは作らないほうが良いそうです。具体的に何が起きるかは確認していませんが、git subtreeは外部ライブラリを取り込む機能として作られているので、まあ直感的にもやめたほうがよさそうです。

また、--prefixオプションに何を指定していたか忘れるといけないので、コマンドの手順はどこかに控えておくとよいでしょう。

連載はこれで終了

これでこの連載は終了となります。チーム開発でも修正、デプロイが可能な環境のベースになっていると思います。

負荷分散はどうするかなど、WordPressを使う上で個別の課題はまだまだありますが、それはまた別のお話ということで。