Boxen使わなくても許されるのは2012年までだよね を書いたのも今は昔、1年間の運用の末にこの度Boxenを卒業しました。なぜBoxenをやめたのか、やめて今はどうしているのか、といった話を書きます。
Boxenのつらいところ
ここで述べるBoxenの問題点の大部分は筆者のBoxenおよびPuppetに対する理解の低さが根底にあります。間違った使い方をしている可能性は十分にあり、適切に使っていればこのような問題は発生しないのかも知れません。しかしながら、深い理解がなければまともに使えないというのもどうかと思いますのでつらつらと並び立てたいと思います。
挙動を把握するのが難しい
BoxenはPuppetの上で動作します。Puppetを便利に使うためのフレームワークみたいな位置づけだと思っています。
Rubyに詳しくなくても、RailsのDSLを組み合わせるととりあえず動くものを作れるように、BoxenもPuppetを知らなくても雰囲気でなんか動くものを書くことができます。が、同時にRubyに詳しくなければRailsの内部動作を調べることができないように、Puppetに明るくなければBoxenの中身を知ることができないのもまた事実。
普段からPuppetを使っているような人はBoxenの中身まで調べられるでしょうが、筆者を含むそうではない大半のエンジニアにとっては、Boxenは完全なるブラックボックスと化し、問題が起こったときに対処するのが非常に困難になります。特にその問題がBoxenに起因するものなのか、Puppetに起因するものなのかが分からないのが辛い 
幸いBoxenの開発は今も非常に活発に続けられており、GitHub上でissueを立てればちゃんと質問に答えてくれる雰囲気はあります 
Boxenの開発についていかないといけない
Boxenの開発が活発なのはいいのですが、活発過ぎてついていくのが大変です。Boxenをアップデートする方法という記事を書いたこともありますが、正直これが本当に正しいやり方なのか未だに不明ですし、アップデートする度に毎回バージョンのチェックをしてまわらないといけなかったりして非常に面倒です。
開発環境の要件が変わることなどそうそう起こることではなく、Rubyのバージョンを上げる時くらいのものでした。Rubyのバージョンが上がるまでにBoxenのバージョンは爆上がりしているので、アップデートするためには先にBoxenをアップデートしないといけないという不要なオーバーヘッドが発生して時間を浪費します。
環境構築に時間がかかる
Boxenによる環境構築がとにかく遅いです。boxenコマンドを実行して完了するまで、最初の一回目は大々的に環境構築を行うので数十分かかるのは致し方ないとしても、一切の変更が不要な場合でも結構な時間を待たされます。
Boxenが実行できなくなっている場合がある
時間がかかるのはその間に他のことをして待っていればいいので、なんとか我慢することができます。
問題なのはBoxenを実行するための環境そのものをメンバーが意図せず壊してしまっている場合です。BoxenはMacに直接インストールしているので、こういうことがたまに起こります。例えば brew upgrade を何気なく実行したら壊れた、ということがありました 
この場合、そもそもBoxenを実行できるように復元しなければなりませんが、その復旧作業は当然ながら手作業です。でもその手作業の末にやりたいことはたかだかRubyのバージョンを上げる程度のことなのです。
最新版が使えないことがある
例えばRubyの新しいバージョンがリリースされたとします。そのときBoxenを使っているとBoxenが対応するまでそのバージョンを使えません。
使えるようになるまでにどれくらいのラグがあるのかは一概に言えないですが、Boxenの構造として個別のプラグインは既に最新版に対応しているのに、肝心のBoxenそのもののバージョンを他のプラグインとの兼ね合いでアップデートできず、結局その最新版を使うことができない、ということも多々起こります。
そしていざ使えるようになったとしても、そこで待ち受けているのは先ほど書いたように「まずはBoxenのアップデートをしなければいけない」という不毛な現実なのです。Rubyをアップデートしたいだけなのに、なんでBoxenのアップデートから始めないといけないのでしょう？
Boxenを入れることに抵抗がある
Boxenは素のMacにインストールします。個人のPCにインストールするのは非常に躊躇われます。
全体的にシステムが重くなる
気のせいかもしれないですが、Boxenを止めたらシェルの起動がめちゃくちゃ速くなりました 
Boxenを置き換える
Boxenでやりたかったことはこの2つです。
- メンバー間の環境の差異を無くしたい
- Macのセットアップを自動化したい
はっきり言って2つ目の要求をプロジェクト用の環境構築ツールに求めるのは筋が悪い。
開発環境はVagrant+VirtualBoxで
開発環境はVagrantを使って共通化することにしました。このあたりのやり方はインターネット上にたくさんあるので詳しくは書きませんが、既に本番サーバを構築するためのChefレシピが存在していたので、それに若干手を入れて開発環境をcookできるようにして、その成果物をVagrant Boxとしてメンバーに配布しています。VagrantとVirtualBoxなら、万が一環境が壊れたとしても
vagrant destroy
vagrant up
するだけでとりあえず環境を戻すことができます。Saharaを使っていないのは、このVagrant Boxは定期的にアップデートされていきBoxごとまるっと入れ替えることを意図しているので、そもそもVagrant内の環境を変更しないからです。
MacからVagrant内で起動しているWebサーバにアクセスするためにDnsmasqを使っています。
MacのセットアップはBrewfile + Homebrew-cask
アプリケーションの開発環境の条件が
- VagrantとVirtualBoxとDnsmasqがインストールされている
- Dnsmasqが正しく設定されている
ことだけになったので手動インストールと簡単なシェルスクリプトで十分に対応可能。あとは各自が必要なツールを必要に応じてインストールします。その部分をどうやるかは個人の自由ですが、筆者は最近よく見かけるHomebrew + Brewfile + Homebrew-caskの組み合わせを使うことにしました。個々の構成要素が非常にシンプルで気に入っています。
ちなみに筆者のBrewfileはこんな感じです -> dotfiles/Brewfile at master · yuku-t/dotfiles
おわりに
というわけでBoxenが辛すぎるのでVagrantとHomebrewを使うようにしたらハッピーになった、というお話でした。
Goodbye Boxen!