5人以下のチームでWordPress案件を開発するときのメモです。
小規模なのでファイル同期にあまり手がかけられない、でもGitとかでキレイに管理はしなくちゃならない、という感じです。
まだ試行錯誤の途中なのですがその経過を含めて。

ファイル構成

こんな感じにしてみました。

Contribute to yousan/circleci_wp development by creating an account on GitHub.

ローカル環境での稼働はpublicディレクトリをドキュメントルートに設定する想定です。
Dockerで動くローカル開発環境のdampを使っています。

ローカル開発環境をもっとたくさんの人に使ってもらいたくてDockerで作りました - Qiita

始めに最近ウェブ開発でローカル環境を使って欲しいなぁ、とすごく思うようになりました。慣れてしまえば開発効率が上がると思うんですけど、その導入が大変なんですよね。仕事で一緒になった方々に手作業で構築していましたが、もっと簡単にできないか...

これで開発用のドメインを example.dev のように割り当てて使っています。

$ cd ~public_html; ln -s ~/git/circleci_wp/public ./

基本的に開発といえばテーマかプラグインを作成することになるのでリポジトリ直下に置きました。
実際の動作では、それらのファイルへシンボリックリンクでアクセスさせています。

以前は実体をpublic/wp/wp-content/themesとかに置いていたのですが、頻繁に使うものなのでいちいち移動するのがすごく大変でこの形になりました。

Composerでのインストール

WordPress自体のインストールはいくつかありますが、Composerを使ってみました。

Using Composer with WordPress

An introduction to Composer and how to manage WordPress core, plugins, and even themes with it. Composer is a dependency...

composer.json のextraでインストール先をpublic/wpにしています。

テーマディレクトリとプラグインディレクトリについてはシンボリックリンクを貼っています。
composerのサブコマンドを定義してあり、composer set-wp-contentで動作させています。

$ composer set-wp-content
> rm -rf public/wp/wp-content/themes
> ln -s ../../../themes public/wp/wp-content/
> rm -rf public/wp/wp-content/plugins

またcomposerでWordPressをインストールするとwp-content類が上書きされるため、post-install-cmdとpost-update-cmdで貼り直しを行っています。

（ここでは書いてなかったですが、wp-config.phpについても置いたほうがよさそうです。

wp-cli.yml

テーマディレクトリ、プラグインディレクトリはWordPressの配下ディレクトリじゃないです。
なのでwp-cliが使えないです。
wp-cli.yml を作成しておくと良さそうでした。　

チームメンバーでの統一

WordPress案件に限らず、チームのメンバーではローカル開発環境の構築や開発用ドメイン名の割当をある程度任せていました。
メンバーはエンジニアですので「これが僕の考えたさいつよの開発環境！」ってありますし。
が、それですとテーブルプリフィクスなどに違いがでるため、最近では統一する方向としています。
ただそれだとおもしろくないので、「僕の考えたさいつよ」な環境はチームや次からのプロジェクトに反映させてもらおうと思っています。

問題点

DBの同期をどうするか、非常に悩んでいます。
以前は開発用の中央サーバを置いてそこをチームメンバーで編集し、そこからダンプなどをさせるという方法をとっていました。
が、ローカルのDBを編集してダンプなどをcomposerのサブコマンドで作成、Gitで管理して…、という方法を検討しています。
ただDBのダーティリードが発生するでしょうから要注意ですね。