小規模チームでのWordPress案件開発でComposerにまかせてみる

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

目次

ファイル構成

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

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

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

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

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

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

Composerでのインストール

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

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-cmdpost-update-cmdで貼り直しを行っています。

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

wp-cli.yml

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

チームメンバーでの統一

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

問題点

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

シェアする

  • このエントリーをはてなブックマークに追加

フォローする