VCCW(ver3.18.0)でWordPress構築~git管理編~

前回のVCCWでローカル環境構築編に続いて、今回はVCCW環境のgit管理についてです。
複数人でWordPressサイトを運用する場合はgit管理が必要になるかと思いますが、VCCW環境のgit管理についてはあまり参考情報がなかったので悩みました…

というわけで、現時点での個人的VCCW環境のgit管理についての見解を書いていきます!

パターン1

そもそも話なのですが、VCCWの.gitignoreを眺めているとgit管理を前提にしていないのでは?と思えてきます。
というのも.gitignoreに/wordpressの記述があって、つまりは子テーマとかを改修したとしても差分が出ないからです。

しかしVCCWはWordmoveというツールを内包しているので簡単に本番環境とローカル環境を同期することができます。
つまり、開発を始める前にWordmoveで最新の本番環境をローカルに同期してから開発すればmasterブランチをpullしたような状態と同じです。
一人で開発したり、プルリクエストのフローが取り込まれていない場合はこれでも特に問題ないかと思います。

ただ、複数人で並行して開発する場合はそうはいきません。
各々が開発を終えた時点で本番環境にデプロイしていてはカオスなので、次はgit管理するパターンを検討してみます。

パターン2

というわけでなんとかgit管理できる方法を考えてみました。
デフォルトの.gitignoreだと改修されることが多いファイルまで除外されてしまうので、以下のようにしてみます。
(まだ模索中です…)

.vagrant
Gemfile
Gemfile.lock
Rakefile
Vagrantfile.sample
Vagrantfile.theme-review
provision/packaging.sh
spec
/wordpress/*
!/wordpress/wp-content
/wordpress/wp-content/*
!/wordpress/wp-content/themes
/wordpress/wp-content/themes/*
!/wordpress/wp-content/themes/使用中のテーマ
!/wordpress/wp-content/themes/使用中の子テーマ
.env

これらのファイルの大半はvagrant upをすれば生成されるので、おそらく問題ないかと思います。
ただ、テーマに関しては管理しておく必要があるのでこんな感じで使用しているデーマだけ差分管理します。
(.gitignoreの書き方が冗長すぎるので、もっといい書き方がないかは宿題ということで)

あと.envはまた後日記事にしますが、デリケートな情報をgit管理しないようにするために必要なので書いておきます。

この.gitignoreを設定した状態で、初回のvagrant upをした差分を全てgit管理しておきます。
まだ試していないので確証はないのですが、おそらくリモートからpullした上でvagrant upを実行すればDB以外は再現される思います。

DBも管理する

この状態でテーマ周りは管理できているのですが、DBが管理されていません。
つまりはpullした上で環境を立ち上げても、デフォルトのテーマで空っぽの環境が立ち上がるだけです。

そこで、これらの差分とセットでDBもgit管理におきます。
まずは仮想環境にアクセスします。

$ vagrant ssh

仮想環境に入ったら、VCCWとセットでインストールされたwp-cliを利用します。
vagrant sshでアクセスしたディレクトリで以下を実行します。

$ wp db export /vagrant/wordpress.sql
Success: Exported to '/vagrant/wordpress.sql'.
# exit

これでプロジェクトルートディレクトリにwordpress.sqlというファイルが生成されているかと思います。
このファイルにDBの情報が格納されているので、git管理します。

このファイルとセットでgit pullした人は、vagrant upした後に以下を実行します。

$ vagrant ssh
$ wp db import /vagrant/wordpress.sql

これでDBの情報も復元されるので、ひとまず開発できる状況になりました。
ただもう少し楽できる方法があります。
プロジェクトルートに以下の内容でprovision-post.shというファイルを作っておきます。

#!/usr/bin/env bash

set -ex

if [ -e /vagrant/wordpress.sql ]; then
  sudo -u vagrant -- wp db import /vagrant/wordpress.sql
fi

このファイルがある状態で初回のvagrnat up、もしくはvagrant reload –provisionを実行すれば自動的にwordpress.sqlをimportしてくれます。

実際には

ここまで書いておきながらですが、複数人で開発する場合はDB はgit管理しない方がいいかなぁと思ってます。
というのも、wordpress.sqlをgit管理したところでminifyされているのでプリクエストで差分も確認できないですし、例えば開発者Aがうっかりwordpress.sqlを生成するのを忘れた状態でmasterブランチを更新し、それをpullした開発者Bがデプロイすると先祖返りしてしまいます。

というわけで、VCCW(というよりもWordmove)を導入している開発環境においてはgit管理についてフロー面での工夫が必要そうです。

現状の個人的見解

諸々の可能性を検討した上で、以下の管理とフローが良いのではと思います。
ここでは二人で開発している前提ですが何人に増えても考え方は同じです。
また、多々登場するWordmoveについては後日改めて紹介しますが、いわばローカル環境とリモートの環境をまるっと同期するツールです。

  1. 開発環境の初期構築した人はパターン2の状態を作ってpushしておく(以下、この人を開発者Aとする)
  2. 後から参加した開発者は上記のブランチをpullしてvagrant upを実行(以下、この人を開発者Bとする)
  3. 開発者BはWordmoveで本番環境のDBをローカルに落とした上で開発を進める
  4. 開発者Bの開発が完了したら出ている差分を全てpushしてプルリクエスト作成
  5. 上記プルリクエストをmasterブランチにマージする
  6. 開発者Aはmasterブランチをpullして開発ブランチを切り、Wordmoveで本番環境のDBをローカルに落とす
  7. 例えば開発者Aが新たにプラグインを導入したりプラグインの設定を変えるとした場合、localで開発とデバッグを終えたpushしてプルリクエストを行う(使いませんがWordpress.sqlも含まれている)
  8. デプロイする前に、開発者AorBが最新のmasterを落とした上でWordmoveで本番環境のDBも落とした仮想環境を作成する
  9. 8の仮想環境からWordmoveでステージング環境にデプロイしてデバッグ
  10. 問題なければ本番環境にデプロイ
  11. あとは2以降の繰り返し

これでDBの先祖返りを防ぎならも複数人で開発ができます。

残る懸念点

しかし、これでもまだ懸念はあります。
例えば以下のようなパターンはどうしたらよいのでしょう。

  • 複数人がDBレベルに変更を加える開発を並行している
    • 例えばプラグインの導入をデバッグしているブランチが複数ある場合、先にリリースしたもん勝ちになってしまう
  • wordpress.sqlが競合した(しかも中身が解読不能)
    • この状態になったことがないので起きるか不明ですが、おそらく人力では対応できないのでは…

ここまでくるとVCCWやWordmoveの話というよりも、WordPressでのgit管理のベストプラクティス的な話になるかと思うので、どなたか知見がある方はアドバイスいただけると嬉しいですmm

おわり

というわけで、まだまだ改善の余地はありそうですがまとめになります。

  • 開発者が一人ならgit管理しなくてもWordmoveだけで運用できる
  • 開発者が複数人いる場合はDBは本番環境から同期した上で開発を進める
  • 並行してDBレベルの開発を行う場合はリリース時期を調整する
  • もしくはDBは管理せず、プラグイン周りはソースで管理せずにローカル・本番のそれぞれで手動運用する

次回は何度も登場してきたWordmoveを使ってリモートにデプロイする方法を書いていきます!
WordPressのgit管理について知見をお持ちの方はぜひご意見いただければと思います。

ではでは