テスト駆動なローカル開発環境の構築方法について

こんにちは。顔が丸くなってきたきたけーです。

ここ一週間、現在、OJTでお世話になっているサービスのローカル開発環境を構築していました。その中で試みた方法が有効だったので、まとめておきます。

この方法が有効な場面

現在、利用されている開発サーバの構築手順が存在しない。存在していても、手順が作成されてから時間が経過しており、現在のサーバの内容と乖離している。
現在、利用されている開発サーバが、その都度その都度、様々な人の追加・修正が加わり、秘伝のタレのようになっている。

テスト駆動なローカル開発方法とは

今回、試みた方法は以下のような内容です。

現在利用されている開発サーバの仕様を明確にするためにserverspecのテストを書く
開発サーバを対象にserverspecのテストを走らせて全て通ることを確認する
構成管理フレームワークのコード(puppetマニフェストやchefレシピ)を書く
VagrantでVMを立ち上げ、3.で作成したマニフェストを適用する
Vagrantで構築したサーバを対象にserverspecのテストが全て通ることを確認する。通るまで、3~5を繰り返す

1~5の手順をミドルウェア単位でインクリメンタルに繰り返し、ひと通りできたら実際にブラウザからページにアクセスする。必要があれば修正を行う。

仕様を明確にする

serverspecの公式サイトに

RSpec tests for your servers configured by Puppet, Chef or anything else

と書かれているようにserverspecのテストの対象はpuppetマニフェストやchefレシピといった、サーバの状態を記述したコードです。コードを適用した状態をテストすることで、コードのテストをおこなうのが本来の目的ですが、
1.の手順で、現在利用されている開発サーバの仕様を明確にするためにテストを記述しています。

長く続くサービスでは、それまでの経緯から、「サーバのlistenしているポート番号」、「設定ファイルの内容・権限・パス」、「利用しているミドルウェア・ライブラリのバージョン」など様々なサーバリソースに癖があります。そのような癖をserverspecのテストに記述していきます。
example数を増やしていくにつれてサーバの仕様が明確になっていきます(良い副作用として、これまで隠れていた不具合が顕在化します)。一度作成したテストは、適切に記述されており、それが通り続けている前提でサーバの仕様としてチーム内での仕様の共有に役立ちます。

この手法による精神的なメリット

serverspecを利用していることから、適切にテストが記述できている前提で完成したコードが正しく機能するのは当然ですが、精神的な面で以下の2点のメリットが考えられます。

明確にした仕様に基づくコード適用後のテストをserverspecで自動化しているため、正しく記述できたか、確認漏れはないか、といった不安な気持ちから解放される
一度に全てのコードを作成するのでなくミドルウェア単位でインクリメンタルに進めていくことにより、確実にゴールに近づいているという気持ちが生まれる