WordPress の開発環境は、その人のワークフローや普段の仕事内容によって適切なものが変わります。
今回の記事では、それぞれの特徴とメリット、デメリットを著者自身の主観と偏見でご紹介します。
この記事は普段 WordPress でなんらかのプログラミングをしているプログラマーが対象で、想定しているユースケースは上級者向けです。
また、それぞれの環境の構築方法には一切触れておりませんので、あらかじめご了承ください。
MAMP 系
もっとも広く利用されているのが、この MAMP とか XAMPP ではないかと思います。
これらは GUI 等がそなわっており、情報量もおおいことから、初心者向けとされています。
ただし、ローカルの OS とファイルシステム等が一枚岩で動作しており、多くのみなさんが使うであろう Linux 系のサーバーとは似て非なるものであるため、デプロイした後の動く動かない問題がどうしても発生してしまいます。
あと、仕組み上バーチャルホストを多用するため、増え続けるバーチャルホストとのおつきあいをどうするかは、避けられない課題ではないかと思います。
Vagrant 系
Vagrant 系は、インフラの構成そのものの共有を可能にするソリューションとして、僕たちの仕事では避けられないものとなりました。
不要になったら Git にコミットしてローカルから削除ということができるのも Vagrant のすばらしい特徴です。
たとえば、VVV という Vagrant 環境は、WordPress のコア開発におけるデファクトスタンダードとして、海外では非常に多くの開発者が使用しています。
僕は、VCCW という違うプロダクトの開発者ですが、VVV にも貢献しており、開発者の Jeremy Felt さんとは何度かアイディアの交換をしたこともあります。
same for me! Thanks for your work with VCCW and VVV!
— Jeremy Felt (@jeremyfelt) June 26, 2016
VCCW は、WordPress サイトの構成をまるごと共有するための環境として開発しています。（WordPress 4.6 のリリースリードの Dominik Schilling さんも VCCW ユーザーなんですよ！）
また、WordPress.org や WordCamp.org を開発するための環境としての WordPress Meta Environment という Vagrant 環境もあります。
他にも Automattic は、自社のホスティングサービスの環境をパートナー向けに Vagrant 環境として公開していますし、大手ホスティング会社の WP Engine は、HHVM の導入を検討する中で Vagrant 環境を公開してコミュニティからのフィードバックを求めました。
このことからも Vagrant 系の開発環境のプライオリティに「共有」があることがお分かりいただけるのではないかと思います。
Vagrant 系のデメリットは、起動時にプロビジョニングが発生するので、どうしても数分の待ち時間が必要となることと、その仮想マシンの性能がやや低いことです。（VCCW では、これを最短で 1分ほどまで縮めることができるようになりました。）
それでも、オープンソースプロジェクトに携わる上では「共有」はワークフローの中で欠かせないスキルなので、Vagrant と VirtualBox はとりあえずインストールしておくべきだと思います。
Docker 系
Docker も仮想環境のひとつですが、こちらは仮想マシンの性能が非常に高いこと、起動が非常にはやいことなど、開発環境としても注目をあびています。
このブログでもとりあげた、Local by Flywheel は美しい GUI や様々なユーティリティで素晴らしい開発環境の一つです。
https://capitalp.jp/2017/01/05/local-by-flywheel/
Wocker もシンプルな CLI インターフェースが、Docker のやたらめんどくさいコマンドラインオプションを解決するアプローチとして素晴らしいですが、Wocker は Vagrant 上で Docker を動かしているので使い勝手がやや変わります。
DockerHub には、Docker 社による WordPress のコンテナもありますので、それもいいかもしれません。
https://hub.docker.com/_/wordpress/
Docker 系は、WordPress のデプロイまでのワークフローになにかいいアイディアが出てくればすごいことになるかもしれません。
Docker の高速なデプロイを活かすには DB とアップロードファイルをどうするかが鍵だと思いますが、海外の開発者コミュニティでは WP-API がその部分を解決するソリューションとして注目されており、そういう意味でも今後が楽しみです。
ただし、ローカル開発環境として使う際に、増え続けるホストをどうするかは大きな問題じゃないかなと思います。
あと、僕は WordPress と WP-CLI は、Nightly バージョンじゃないと困るのですが、そういうマニアックな要望があるさいには結局いろいろ頑張る必要があります。
Vagrant のように git clone して vagrant up みたいな感じでさっと好みの環境を再現できれば、たくさんのウェブサイトを管理している場合にも便利じゃないかと思うのですが、そのあたりをうまくやる方法を見つけることができませんでした。
とはいえ、VCCW では Docker を使用して プロビジョナーに使われている Ansible の Playbook のテストを行っており、Docker も僕にとってはとても重要な技術のひとつです。
https://travis-ci.org/vccw-team/vccw/jobs/195263878
上のリンク先は、日本語のWordPressが起動していること、そこに期待通りのプラグインがインストールされていることなどを自動的にテストしてることを確認できる Travis CI のログです。
シェルスクリプト系
WP-CLI には、wp server というコマンドがあり、これを使えば MySQL を用意するだけで WordPress を起動することができます。
これによる最も多いユースケースは、Travis CI 等の CI サービス上で WordPress を動作させることです。
それには、WordPress のバージョン等を環境変数でセットできる必要があり、古いバージョンの WordPress や ベータ版でのプラグインの動作確認を行うことなどを可能にしています。
WP-CLI の wp scaffold plugins をつかってプラグインの雛形を作成すると、シェルスクリプトも自動的に生成されます。
https://github.com/wp-cli/wp-cli/blob/master/templates/install-wp-tests.sh
これは、Travis CI 上のコンテナ内の /tmp に WordPress をインストールして phpunit でテストを実行することを可能にするためのものです。
以下の URL は実際の WordPress プラグインに対するテストのログで、よく見ていただくと複数の PHP のバージョンと複数の WordPress のバージョンの組み合わせに対してテストを実行していることがわかります。
https://travis-ci.org/miya0001/simple-map
あと以下のシェルスクリプトは環境変数で 有効化するテーマ等も指定できるようになっており、E2E テストの自動化も想定しています。
https://github.com/vccw-team/install-wp
以下の環境は、デモや動作確認等でさっと WordPress が必要なときによく使用しているもので、単純に起動回数だけなら僕が最も多く使用しているものかもしれません。
https://github.com/miya0001/wp-instant-setup
まとめ
僕はケースバイケースで複数の開発環境を使い分けています。
これによってたとえば、GitHub の Issue で投稿された環境を数分で用意したり、会ったこともない人たちとオープンソースプロジェクトに取り組んだりしています。
開発環境はみなさんが思っているよりもはるかに簡単で多様なので、臨機応変に付き合っていくといいのではないかと思います。
ところで、これらの開発環境で共通の鍵を握る重要なプロダクトがあります。それが WP-CLI です。
WP-CLI は、手作業でコマンドを打つことよりも、WordPress 周りの環境の構築の自動化を可能にすることに本当の価値があります。
Vagrant にしろ Docker にしろ、わずかな WP-CLI コマンドの修正で、みなさんご自身のお好みの開発環境をつくることができますので、既存のプロダクトを使ってオレ流なものを作るのも選択肢としてはありではないでしょうか。
コメントを残す