VCCW v3での変更点と新機能まとめ

VCCW v3をリリースしました。

主な変更点

	v2	v3
OS	CentOS 5	Ubuntu 16.04
Provisioner	Chef	Ansible
PHP	5.4	7.x
Ruby	2.1	2.3
Node	0.10	6.x

WP-CLI について

VCCW v2 では、通常版の WP-CLI をインストールしていましたが、v3 では、nightly バージョンをインストールしています。

WP-CLI の nightly バージョンは、開発環境で使用するレベルでは問題がないよう十分にテストされており、最新の機能をいち早く使うことができます。

私自身が WP-CLI のチームメンバーであり、VCCW そのものを WP-CLI のドッグフーディングとして使用することにしました。

VCCW v3 のゴール

VCCW のゴールは、単に開発環境を手っ取り早く用意できるようにするということだけではなく、WordPressが動作する環境そのものを、ワークフローも含めて共有することです。

従来の方法では、せいぜい WordPress のファイルやデータベース等の共有が限界で、開発チームのメンバーはそれらを入手後に、独自の開発環境で再構築する必要がありました。

VCCWでは、単に WordPress のファイルだけではなく、それが動作する環境や、phpunit などのテスト環境、デプロイツールなど、ワークフローをまるごと共有できるようにしていきたいと思っています。

改善点

Boxのサイズが小さくなりました。

VCCW v2で使っていた miya0001/vccw というBoxのサイズは1.5GBほどあったのですが、v3用の vccw-team/xenial64 は、約670MBとなりました。

これによって初回の起動が早くなり、ディスク容量的にもやさしくなりました。

従来のものがなんでこんなに大きかったかというと、それに必要な処理をちゃんとしてなかったからです。。。すいませんすいません。

起動が早くなりました。

VCCW v3 では、Apache や PHP、MySQL などの APT パッケージを Box 側でプリインストールしています。

一方で VCCW 起動時には apt-get install によるパッケージのインストールを行っていません。

これによってプロビジョニングが早くなりました。

もし常に最新版のものを使用したい場合には、apt-get upgrade 等を各自おこなってください。

僕の環境では概ね5分以内で起動します。（初回だけ Box のダウンロードに時間がかかるので20分ぐらいかかるかも。）

$ time vagrant up

...

real   4m38.442s
user   0m5.248s
sys    0m2.590s

エラー処理の改善

たとえば、phpunit などの Composer のライブラリのインストールが失敗しても、WordPress本体の動作に影響が無い場合は、そのままインストールを継続するようになっています。

もし、エラーが出た場合は、プロビジョニング終了後に vagrant provision を実行してください。

さらにフレキシブルになった設定ファイル

たとえば、なんらかの npm モジュールや Composer ライブラリをインストールしたい場合は、以下のように site.yml に記述することで、それらがインストールされます。

(site.yml は、Vagrantfile と同じ場所においてください。)

site.yml

npms:
  - grunt-cli
  - http-server
composers:
  - phpunit/phpunit:*
  - phpmd/phpmd:*

Ruby の Gem や Composer、WP-CLI のコミュニティコマンド なども同じようにインストールできます。

また、以下のように site.yml に記述することで、プロビジョニングを2分弱ほどで完了させることもできます。

site.yml

plugins: []
ruby_gems: []
npms: []
composers: []
wp_cli_packages: []

これらは、グローバルな設定 ~/.vccw/config.yml に記述しておけば、毎回記述する必要がなくなります。

~/.vccw/config.yml

linked_clone: true
cpus: 2
memory: 1024
lang: ja

設定ファイルのデフォルトは以下です。

グローバル設定

上述のようにVCCWでは、~/.vccw ディレクトリに config.yml を設置することで、みなさんの好みのデフォルト値を設定することができますが、v3からは ~/.vccw/provision-post.sh というファイルを設置するとそのシェルスクリプトも自動的に実行されるようになりました。

#!/usr/bin/env bash

set -ex

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

この例では、プロビジョニング完了後に wordpress.sqlというファイルがあれば、それを自動的にインポートします。

こうしておくことで、あらかじめ wp db export /vagrant/wordpress.sql としておけば vagrant destroy をしても次に vagrant up したときには元の状態が復活します。

なお、このシェルスクリプトは、ゲストマシン内で実行されますのでパス等にご注意ください。

vagrant-hostsupdater について

VCCW では、指定したホスト名（デフォルトでは vccw.dev）でアクセスできるように、Vagrant の vagrant-hostsupdater プラグインを使用する仕様になっていますが、v2 では、これがなくても IP アドレスでアクセスすれば、それなりに WordPress が動作するようになっていました。

VCCW v2 では、これを実現するためにホスト名の帳尻をあわせる WordPress プラグインをインストールしていましたが、いろいろなユースケースを検討した結果、このプラグインですべての問題が解決されるわけではないという結論になりました。

今後は、Vagrant の vagrant-hostsupdater プラグインをご利用いただくか、手作業で hosts ファイルにホスト情報を記述する等の方法でご対応をお願いします。

これは、macOS ユーザーにとっては、あまり問題になることはありませんが、Windows ユーザーにとってはややめんどくさいかもしれません。

新機能

Mailcatcher

Mailcatcher を使用すると WordPress が送信するすべてのメールをブラウザで確認することができます。

v3からデフォルトで起動するようになっていますので、以下のURLにアクセスしてください。

Mailcatcher は、送信するメールの不具合等で落ちることもあるようです。その場合は以下のコマンドで再起動してください。(コマンドはゲストマシン内で行うこと)

$ sudo service mailcatcher start

WP-CLI のエイリアス

WP-CLI のエイリアスという機能を使用するといちいち vagrant ssh することなく、WP-CLI のコマンドを実行することができます。

(ローカルにも WP-CLI のインストールは必要です。)

必要な設定ファイルを wp-cli.yml というファイル名で自動的に生成するようになっていますので、あとは vagrant ssh-config の出力を ~/.ssh/config に記述するだけです。

~/.ssh/config

Host vccw.dev
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /path/to/.vagrant/machines/vccw.dev/virtualbox/private_key
  IdentitiesOnly yes 
  LogLevel FATAL
  ForwardAgent yes 

以上が完了すると以下のように WP-CLI コマンドを使用することができます。

$ wp @vccw plugin install wp-total-hacks

playbook-post.yml

従来から Vagrantfile と同じディレクトリに provision-post.sh というファイル名でシェルスクリプトを設置すれば、プロビジョニングの最後にこのシェルスクリプトが実行されるようになっていましたが、v3 からは、シェルスクリプトだけでなく Ansible のファイルを設置することもできるようになりました。

たとえば wp db export /vagrant/wordpress.sql でエクスポートした SQL ファイルを自動的にインポートするには以下のような感じです。

playbook-post.yml

- hosts: all
  become: yes

  tasks:

  - stat:
      path: "/vagrant/wordpress.sql"
    register: is_sql_file
  - name: Run `wp db import /vagrant/wordpress.sql`
    become: no
    shell: /bin/bash -lc "wp db import /vagrant/wordpress.sql"
    when: is_sql_file.stat.exists == true

以下の例はプロビジョニング完了後に apt-get upgrade する例です。

playbook-post.yml

- hosts: all
  become: yes

  tasks:

  - apt: update_cache=yes
  - apt: upgrade=dist

この機能を使えば phpMyAdmin をインストールしたりウェブサーバーを Nginx に変更することもできます。

その他の細かい機能

WP-CLI のコマンド補完 (Bash Completion)

WP-CLIコマンドがタブキーで補完されます。ちょっと気持ちいいです。

WordPress ユニットテスト用のコマンド

$ install-wp-tests

と打つと、WordPress プラグインのユニットテスト用の WordPress 環境が自動的にセットアップされます。

$ wp scaffold plugin-tests oreore

というコマンドで自作プラグインにPHPUnit用のコードを仕込んで、phpunit と叩けばユニットテストが走ります。

コマンドを実行するたびに新品が作成されるので地味に便利。

/tmp 以下に作っていますので、ゲストマシンを再起動すると消えてくれます。

WP-CLI のテスト用のコマンド

以下のコマンドで自作 WP-CLI コマンドを Behat でテストするための WordPress 環境がセットアップされます。

$ install-package-tests

これも上述と同様に /tmp 以下に作っていますので、ゲストマシンを再起動すると消えてくれます。

WordPress Coding Standards

自作プラグインやテーマのディレクトリの中で以下のコマンドを実行すると、そのテーマやプラグインが WordPress のコーディングスタンダードに沿っているかどうかを簡単にチェックできます。

$ wpcs *.php

WordPress i18n Tools

自作プラグインやテーマを国際化するときに便利なコマンドです。

$ makepot wp-plugin .

みたいな感じで pot ファイルを作ることができます。

廃止

• 基本的に npm モジュールはグローバルにインストールするものではなく、プロジェクト単位でインストールするケースの方が多いためプリインストールする必要性がそれほど感じないことと、site.yml や ~/.vccw/config.yml に各自記述していただければいいので、プリインストールするのをやめました。
• v2 では、phpenv が入っていましたがこれもやめました。テストが大変なわりにあまり必要性を感じなかったからです。

ドキュメントについて

以下のリポジトリの v3 というブランチで作業をしているのですが、英文が得意ではないので手伝ってくれる方を絶賛募集中です。

ドキュメントがある程度のクオリティになったところで、正式版としてリリースしたいと思っています。