WordPressのサイト開発を継続的に行う場合、色んな問題が付きまとってくる。え?FTPでバックアップ? それでもいいけどさ!
本体やプラグインのバージョンUP対応
WPは開発が盛んなため、結構な速度でコアのバージョンが上がっていく。この前3.8だったのに3.9になり4.1になる。気軽にアップデートするのは良いのだけど、開発するとなると上げたものは戻せないといけない。これはプラグインにも同じことが言える。1.5→1.6にして何か動作しなかった場合、1.5に戻せるようにしないといけない。
WordPress本体並びに利用するプラグインをComposor等で構成管理できるにすることが求められるが、その辺はCommand line interface for WordPress | WP-CLIを使うのが最も簡単そうだ。ただこれ、バージョン指定でのUP/Downが出来るかどうかが気になるけど。
環境(ドメイン)が違う問題
WordPressの困った点は、画像の保存パスなどを絶対パスで入れ込んでしまうこと。こんな感じでDBに登録されてしまう。相対パスじゃなくて。なんでなんだろうこれ。
<img src="http://fkcorporation.co.jp/wp-content/uploads/2014/05/order-calendar.jpg" alt="order-calendar" class="img-responsive">
当然ローカル環境なんかでは自分の適当なホスト名が入ってしまうので、これを本番環境に移行する際にはホスト名の書き換えを直接DBを触って変更する必要がある。ステージング環境のWPを本番に移す時も同じことが言えると思うので、その辺も一括で管理できるデプロイツールが求められる。
Githubにwordmoveというruby製のライブラリがあり、どうもその辺の差分を吸収してくれるナイスガイのようだ。ホスト名等の環境依存やローカル、ステージング、本番の3つのやり取りや、ステージング環境のプラグインフォルダのみを移行するなんてこともできるみたい。
で、この辺をAnsibleかfabricでまとめないとダメか
- Vagrantで環境をセットアップ
- wp-cliを入れる
- wpをインストールして動くようにする
- テーマをセットアップする
- プラグインをセットアップする
- データベースの中身を入れる
- wordmoveでローカルをステージングにpush
DBのマイグレーションなんかもやってくれるのかな。多分そうだよね。-allでpushする際に環境依存の情報だけ書いておくと良さそうだね。プラグイン開発なんかやった日にはテストコードの準備も必要だし。WP本体の関数やフィルターのテストコードは要らない気がするけど、自分のプラグインのテストコードは必要だよね、一般的には。
結局のところ
WordPress開発って色々めんどいです。