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
と同じ場所においてください。)
npms:
- grunt-cli
- http-server
composers:
- phpunit/phpunit:*
- phpmd/phpmd:*
Ruby の Gem や Composer、WP-CLI のコミュニティコマンド なども同じようにインストールできます。
また、以下のように site.yml
に記述することで、プロビジョニングを2分弱ほどで完了させることもできます。
plugins: []
ruby_gems: []
npms: []
composers: []
wp_cli_packages: []
これらは、グローバルな設定 ~/.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
に記述するだけです。
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 ファイルを自動的にインポートするには以下のような感じです。
- 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
する例です。
- 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 というブランチで作業をしているのですが、英文が得意ではないので手伝ってくれる方を絶賛募集中です。
ドキュメントがある程度のクオリティになったところで、正式版としてリリースしたいと思っています。