今回は、ローカルに開発環境を構築するときに、どの方法で作ればいいか?について書きたいと思います。手動でやるか、あるいはVagrantやDockerなどの仮想化技術を用いるか、などです。
開発環境の構築は、新しくメンバーが入ったときなどにまずやる事になると思います。ここがしっかりできていると、オンボーディングの体験がよくなります。逆になかなか開発環境の構築ができないと、不安にさせてしまうかもしれません。
開発環境の構築は、地味だけどしっかりと整えておきたいところです。この記事では私がチームで開発したときにつまずいた経験などを元に整理してみます。開発環境を構築するときの参考になればうれしいです。
この記事は、開発環境を準備しようとしているエンジニアの方を対象としています。新しいメンバーを迎え入れる予定の方など、です。ソフトウェアの種類は、ウェブアプリケーションをGitで管理しているような構成を想定していますが、そうでなくても参考になるかと思います。
テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。
ローカルの開発環境とは
この記事でいうローカルの開発環境とは、「ソフトウェアの開発をローカルの端末で行うための環境」のことをいいます。開発環境の構築の流れはプロジェクトによって違うと思いますが、基本的には次のような形になると思います。
- ソースコードをダウンロードする
- 依存ライブラリをインストールする
- ミドルウェアをダウンロード、インストールする
- 環境変数を設定する
- ミドルウェアを立ち上げる
- 開発用のデータを挿入する
- アプリケーションを起動する
他にも、ソフトウェアの種類によってはホストの設定などが必要になったりします。こうした手順をとおして開発のための準備を行うのが、ローカルの開発環境構築になります。
いつローカルに開発環境を構築するか
ローカルに開発環境を構築するときは、どんなときがあるでしょうか。たとえば次のようなときに開発環境を構築すると思います。
- 端末が新しくなったとき。端末が故障した、買い替えたときなど
- 新しくメンバーが入ったとき
- 開発環境が動かなくなったとき。ミドルウェアの実験などで起こったりする
実際にソフトウェアを開発していると、開発環境を構築するタイミングは思ったよりあると思います。開発に携わるメンバーがふえるほど、その機会もふえていくことになります。
なぜローカルに開発環境を構築するのか
ローカルの開発環境を構築する目的は、ソフトウェアの開発などの作業をローカルで行えるようにするためです。
「開発など」としたのは、開発環境を構築するのはエンジニアだけではないからです。デザインの検証をするためにデザイナーの方が行うかもしれませんし、データ分析のためにビジネスサイドのメンバーが行うこともあると思います。
このため、ローカルでの開発環境の構築は「手元で動作させたいと思った人が構築できる」くらいハードルが低い方がいいといえます。
ローカルの開発環境の構築方法を決めるときの指標
ローカルに開発環境を構築する方法はいくつかあります。それらを見る前に、開発環境を構築するときに考慮するべき指標を次にまとめてみます。
番号 | 指標 | 備考 |
---|---|---|
1 | 自動化のコストが低いこと | - |
2 | 構築が簡単であること | 少ない手数で構築できるか |
3 | 起動が簡単であること | 少ない手数で起動できるか |
4 | 起動が早いこと | - |
5 | 端末によらないこと | WindowsやMac、Linuxで使えるか |
6 | 開発体験がいいこと | デバッグやテストはしやすいか |
7 | 消費メモリが少ないこと | - |
8 | 再現性があること | どの端末の環境で行っても同じ結果になるか |
9 | インフラの知識がいらないこと | 起動に知識は必要ないか |
10 | 本番環境と差がないこと | - |
11 | 構成を把握しやすいこと | コードを見て構成が分かるか |
12 | 環境が汚れないこと | 端末にインストールや設定をしないか |
これらの指標を押さえつつ、ではローカルに開発環境を構築するときにどの方法を選択していけばいいかを次に書いていきます。
ローカルに開発環境を構築する方法の比較
前の章で書いた指標をふまえた上で、ではどのような方法が考えられるのかについて書いていきます。まず、ローカルに開発環境を構築するには、大きく「手動でやるか」「自動化するか」に分けられます。
また、自動化についても、仮想化の手法が「ホスト型」か「コンテナ型」かに分けられます。この上で、ローカルに開発環境を構築する方法として次の3つについて考えます。
- 手動で端末上に構築する
- ホスト型の仮想化ソフトウェア上に構築する
- コンテナ型の仮想化ソフトウェアを用いて構築する
1. 手動で端末上に構築する
まずひとつめは、その名のとおりソースコードのダウンロードやライブラリのインストール、ミドルウェアの準備などを手動で、ローカルの端末に対して行う方法です。
ソフトウェアの種類によりますが、起動が早く、またデバッグがしやすい、テストの実行が早いといったメリットがあります。開発環境の構築を自動化するコストをかける必要がないという最大のメリットがあります。
この方法は、チームメンバーがひとりまたは数人で、かつソフトウェアがProduct Market Fitを達成しておらず、開発スピードがなにより重要なタイミングで積極的にとりたい方法といえます。
2. ホスト型の仮想化ソフトウェア上に構築する
VagrantやVirtualBoxを用いてローカルの端末に仮想的なOSを立ち上げて、Ansibleなどのプロビジョニングツールを用いて開発環境を構築する方法です。
OSを自由に使えるので、開発するソフトウェアがカーネルパラメータを設定するなどOSと関わりが強いものであれば、この方法が適しているといえます。また、ローカルの端末のOSがWindowsでもMacでも差が出ません。
本番環境でコンテナを使っていない場合、ローカルの開発環境と本番環境で差をなくすことができます。プロビジョニングツールで構成をコードとして記述するので、どんなミドルウェアが使われているかも把握しやすいです。仮想的なOSを使うので、端末の環境も汚れません。
一方で、この方法はプロビジョニングに時間がかかるというデメリットがあります。OSから立ち上げるので、起動も遅く、消費メモリも大きくなりがちです。
仮想化ソフトウェアのバージョンによって起動できないなどのトラブルがなにかと起きたりします。インフラの知識がないと対応できないことが出てきます。
3. コンテナ型の仮想化ソフトウェアを用いて構築する
ローカルの端末のOSやカーネル部分を使って、ミドルウェアなどのコンテナを立ち上げることで開発環境を構築する方法です。たとえばDocker Composeを用いれば、コマンドひとつで開発環境が立ち上がります。起動も早いです。
ファイルに定義した内容で開発環境が立ち上がるので、使っているミドルウェアなどの構成が把握しやすく、依存関係も定義できるので再現性もあります。
起動する人はインフラの知識がほとんど入らないので、デザイナーなど非エンジニアの方でも環境を作りやすいです。本番環境でコンテナを使っているなら環境に差も出ませんし、開発端末の環境も汚れません。
ただ、環境によってはMacで遅いという問題があったりします。いくらか早くするためのチューニングの方法はありますが、自動化のコストがかかるといえます。
ローカルに開発環境を構築する方法
以上のことをふまえて、ソフトウェアの種類やチームの状況に応じた選択について案を書いてみます。まず大前提として、どの方法を使うかは本番環境の構成に大きく依存すると思っています。本番環境がコンテナを利用していれば上記の3、そうでなければ2か3がとり得るかなと思います。
「1. 手動で端末上に構築する」は、開発メンバーが1〜3人くらいで、ソフトウェアがProduct Market Fitを達成しておらず、開発スピードがなにより重要なときにとり得る方法といえます。ギリギリまでこの方法でがんばりたいです。
「2. ホスト型の仮想化ソフトウェア上に構築する」は、本番環境にコンテナを利用しておらず、Ansibleなどのプロビジョニングツールで構築している場合に適しています。ソフトウェアがカーネルと深く関わっているときはこの方法が開発しやすいです。
この方法は開発環境を構築するのがほとんどエンジニアの場合のみに採用するのがよさそうです。開発メンバーが使っているOSがWindows/Macなどいろいろある場合はこの方法が差が出にくいのでいいかもしれません。
「3. コンテナ型の仮想化ソフトウェアを用いて構築する」は、本番環境にコンテナを使用している場合に積極的にとりたい方法です。非エンジニアの方でも環境構築しやすくしたい場合にも有用です。
個人的には、ギリギリまで手動で構築しつつ、必要なタイミングでDocker Composeを用いて自動化する、というやり方がいいと思っています。これはソフトウェアの種類やチームの状況によって変わるので、参考程度にしていただければと思います。
開発環境の自動化において大切なこと
ローカルへの開発環境の構築を自動化するときに大切なことは、自動化したコードをメンテナンスすることだと思います。
開発環境の構築を自動化したはいいものの、メンテナンスされておらず、新しく構築する人がすんなりと構築できないケースをよく見ます。たとえば、新しく構築を試して、できなかったら修正し、自動化のコードを変更するルールを導入するなど、仕組みもセットで決めるべきかな、と思っています。
まとめ
ローカルに開発環境をスムーズに構築できると、新しいメンバーのオンボーディングもふくめてチームの生産性が大きく向上すると思います。メンバーやチームの状況に応じて適切な方法で構築できる仕組みがあるといいです。