WordPress開発快適化計画 ~ Wordmoveの簡単導入とメリット・デメリット ~
早く冬が来ないかなとソワソワしているノリフミです。
前回、VCCW on WP-CLIにてWordPressの使い方を紹介しました。
Wordmoveを使用してみて、Wordmoveだけでは割と限界があることに気づいてしまいました。
今回はもっと簡単にWordmoveを導入する方法と運用に当たってのメリット・デメリットをご紹介します。
※ 当記事では、Vagrantをインストール済みで、サーバーでWordmoveを公開しており、そのサーバーへssh接続できるものとして話を進めます。
目次
Wordmoveの現状
コマンド
init (wordmoveの設定ファイルであるMovefileを生成)
pull (指定環境を元に同期する)
push (実行環境を元に同期する)
-w, [–wordpress], [–no-wordpress]
-u, [–uploads], [–no-uploads]
-t, [–themes], [–no-themes]
-p, [–plugins], [–no-plugins]
-m, [–mu-plugins], [–no-mu-plugins]
-l, [–languages], [–no-languages]
機能フォルダ単位を同期するオプション
-d, [–db], [–no-db]
DBを同期するオプション
-e, [–environment=ENVIRONMENT]
同期環境を複数設定した際に環境を指定するオプション
[–all], [–no-all]
文字通り全てを同期するオプション
メリット
- ローカル、サーバー間などの別環境のファイルからDBまで簡単に同期できる
- 同期コマンド(pull,push)にオプションをつけると機能フォルダ別に同期できる
- 複数環境も設定ファイルに定義しておくと-eオプションで簡単に同期できる
- 同期時にDBのバックアップがとられる
デメリット
- ファイル単位の同期はできず、機能フォルダ単位でしか同期できない
- ファイルの差分は無視される(恐らく更新日時の新しいものが同期される)
- 差分が無視されて同期されるため、古いファイルは消滅する
- 間違えてpullやpushしたら取り返しがつかない
今回の妄想
Wordmoveは複数人開発の際、上記デメリットの点を引き起こしがちです。
今回の妄想ではWordmoveの役目は主にDBの同期とし、ソース管理はgitに任せます。
Wordmoveで管理する項目
- アップロード系の変更 ( -u )
- プラグイン系の変更 ( -p )
- language系の変更 ( -l )
- WordPress自体のバージョンアップ ( –all )
- その他DBの変更 ( -d )
テーマ以下は基本的にDBに影響を与えないため、git管理とします。
作業の基本的な流れ
- ローカルに環境構築
- ローカルで作業を進める
- stagingに作業分を同期し、テストする
- productionに作業分を同期し、確認する
- gitにcommitする
複数人開発時、上記工程後の他メンバーは
- git pull
- Wordmoveで管理する項目に変更があればwordmove pull -dpu
Vagrantで環境構築
＃ 適当なフォルダを生成
mkdir wordpress
cd wordpress
# Vagrantfileを生成し設定する
vim Vagrantfile
# nginx設定ファイルを生成
vim nginx.conf
# 設定したipとドメインをhostsに追記
sudo sh -c 'echo "192.168.33.123 example.com" >> /etc/hosts'
# 設定問題なければVagrant起動
vagrant up
…
….
…..
ここ割と長いですが、最後まで無事終了すれば環境構築完了です。
ブラウザからアクセス後、サイト情報を入力し初期設定を完了させてください。
上記構成だと
サイトURL : http://example.com
mysqlユーザー : root
rootユーザーパスワード : root
mysqlデータベース : wordpress
になります。
Gitの設定
初回登録の場合
# Git管理を始める
git init
# 全てをGitに登録する
git add --all
# 確定させる。適宜mオプションでコメント設定
git commit -m 'wordpress install'
# 初めてのpushなので先にRepositoryの場所を決める
git remote add origin GITURL
# branchを設定してpushを実行する
git push -u origin master
決まり文句ですね。
既存Repository使用の場合
# srcディレクトリ削除
rm -rf src
# Repositoryをsrcの名前でclone
git clone GITURL src
※ GITURLは適宜Gitの対象RepositoryのURLに変更してご利用ください
Wordmoveの設定
# Wordmove設定ファイル修正
vim src/Movefile
コメントがある箇所と、local部も調整した場合は適宜設定してください。
※ local + 1環境(productionのみなど)の場合、wordmove push or pull時にeオプションにて同期先環境を選択する必要はなくなります。
Wordmoveの使い方
Vagrant内にWordmoveをインストールしているため、Vagrant内のドキュメントルートまで移動する必要があります。
# Vagrant内に接続
vagrant ssh
# ドキュメントルートまで移動
cd /vagrant/src
使用例1（プラグインをインストールし、テーマ以下の調整を行なった場合）
- 改修者がstagingに同期し確認後、productionへ反映、最後にgitに反映
wordmove push -e staging -dpt
wordmove push -e production -dpt
git commit & push - 他メンバーがデータ同期
wordmove pull -e production -dp
git pull
使用例2（ブログ引っ越しにて過去記事の画像付きインポートを行なった場合）
- 改修者がstagingに同期し確認後、productionへ反映
wordmove push -e staging -du
wordmove push -e production -du - 他メンバーがデータ同期
wordmove pull -e production -du
その他コマンドについては、上記をご参考ください。
まとめ
これだけ長々と書きましたが、、、
一人の場合はWordmoveだけで管理し、キリのいいところでgitに反映すれば問題ないと思います。
複数人の場合はWordmoveを使った際に、予期せぬ消滅が多々あるので、DB関連の同期のみにしたほうがいいですよ！
というお話でした。
最後までご覧いただきありがとうございました！
