前回のVCCWでローカル環境構築編に続いて、今回はVCCW環境のgit管理についてです。複数人でWordPressサイトを運用する場合はgit管理が必要になるかと思いますが、VCCW環境のgit管理についてはあまり参考情報がなかったので悩みました...というわけで、現時点での個人的VCCW環境のgit管理についての見解を書いていきます!パターン1そもそも話なのですが、VCCWの.gitignoreを眺めているとgit管理を前提にしていないのでは?と思えてきます。いうのも.gitignoreに/wordpressの記述があって、つまりは子テーマとかを改修したとしても差分が出ないからです。VCCWはWordmoveというツールを内包しているので簡単に本番環境とローカル環境を同期することができます。開発を始める前にWordmoveで最新の本番環境をローカルに同期してから開発すればmasterブランチをpullしたような状態と同じです。一人で開発したり、プルリクエストのフローが取り込まれていない場合はこれでも特に問題ないかと思います。複数人で並行して開発する場合はそうはいきません。各々が開発を終えた時点で本番環境にデプロイしていてはカオスなので、次はgit管理するパターンを検討してみます。パターン2というわけでなんとかgit管理できる方法を考えてみました。デフォルトの.gitignoreだと改修されることが多いファイルまで除外されてしまうので、以下のようにしてみます。upをすれば生成されるので、おそらく問題ないかと思います。テーマに関しては管理しておく必要があるのでこんな感じで使用しているデーマだけ差分管理します。(.gitignoreの書き方が冗長すぎるので、もっといい書き方がないかは宿題ということで)あと.envはまた後日記事にしますが、デリケートな情報をgit管理しないようにするために必要なので書いておきます。upをした差分を全てgit管理しておきます。upを実行すればDB以外は再現される思います。DBも管理するこの状態でテーマ周りは管理できているのですが、DBが管理されていません。pullした上で環境を立ち上げても、デフォルトのテーマで空っぽの環境が立ち上がるだけです。そこで、これらの差分とセットでDBもgit管理におきます。仮想環境にアクセスします。ssh仮想環境に入ったら、VCCWとセットでインストールされたwp-cliを利用します。sshでアクセスしたディレクトリで以下を実行します。exitこれでプロジェクトルートディレクトリにwordpress.sqlというファイルが生成されているかと思います。このファイルにDBの情報が格納されているので、git管理します。upした後に以下を実行します。/vagrant/wordpress.sqlこれでDBの情報も復元されるので、ひとまず開発できる状況になりました。楽できる方法があります。プロジェクトルートに以下の内容でprovision-post.shというファイルを作っておきます。–provisionを実行すれば自動的にwordpress.sqlをimportしてくれます。git管理しない方がいいかなぁと思ってます。いうのも、wordpress.sqlをgit管理したところでminifyされているのでプリクエストで差分も確認できないですし、例えば開発者Aがうっかりwordpress.sqlを生成するのを忘れた状態でmasterブランチを更新し、それをpullした開発者Bがデプロイすると先祖返りしてしまいます。いうわけで、VCCW(というよりもWordmove)を導入している開発環境においてはgit管理についてフロー面での工夫が必要そうです。諸々の可能性を検討した上で、以下の管理とフローが良いのではと思います。ここでは二人で開発している前提ですが何人に増えても考え方は同じです。登場するWordmoveについては後日改めて紹介しますが、いわばローカル環境とリモートの環境をまるっと同期するツールです。上記プルリクエストをmasterブランチにマージする開発者Aはmasterブランチをpullして開発ブランチを切り、Wordmoveで本番環境のDBをローカルに落とす例えば開発者Aが新たにプラグインを導入したりプラグインの設定を変えるとした場合、localで開発とデバッグを終えたpushしてプルリクエストを行う(使いませんがWordpress.sqlも含まれている)デプロイする前に、開発者AorBが最新のmasterを落とした上でWordmoveで本番環境のDBも落とした仮想環境を作成する8の仮想環境からWordmoveでステージング環境にデプロイしてデバッグ問題なければ本番環境にデプロイあとは2以降の繰り返しこれでDBの先祖返りを防ぎならも複数人で開発ができます。残る懸念点しかし、これでもまだ懸念はあります。以下のようなパターンはどうしたらよいのでしょう。複数人がDBレベルに変更を加える開発を並行している例えばプラグインの導入をデバッグしているブランチが複数ある場合、先にリリースしたもん勝ちになってしまうwordpress.sqlが競合した(しかも中身が解読不能)この状態になったことがないので起きるか不明ですが、おそらく人力では対応できないのでは...ここまでくるとVCCWやWordmoveの話というよりも、WordPressでのgit管理のベストプラクティス的な話になるかと思うので、どなたか知見がある方はアドバイスいただけると嬉しいですmmおわりというわけで、まだまだ改善の余地はありそうですがまとめになります。開発者が一人ならgit管理しなくてもWordmoveだけで運用できる開発者が複数人いる場合はDBは本番環境から同期した上で開発を進める並行してDBレベルの開発を行う場合はリリース時期を調整するもしくはDBは管理せず、プラグイン周りはソースで管理せずにローカル・本番のそれぞれで手動運用する次回は何度も登場してきたWordmoveを使ってリモートにデプロイする方法を書いていきます!WordPressのgit管理について知見をお持ちの方はぜひご意見いただければと思います。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。