VMWareを使って様々なプロジェクトの開発やビルド環境を仮想環境で共有しようと考えたが、いろいろ発見があったので書いてみる。
まずゲスト開発者の視点と担当の開発者の視点で要求がかわってくることに気がついた。前者は簡単に環境に触れられることを期待し、後者は日常の生産性を重視する。簡単に触れることを踏まえるとゲストOS上にIDEなどを揃えてしまうことを考えるが、EclipseなどのIDEはメモリを結構食う。連携する複数のプロジェクトの仮想環境を同時に動かす場合に仮想環境ごとにEclipseを立ち上げていてはホストOSのリソースが枯渇してしまう。
さらにソースコードをゲストOSだけに置いてしまうと、仮想環境を起動していないとソースが見れない、プロジェクトをまたいでソースコードを検索できないといったことが起きる。これらを解決しようとすると結局ホストOSですべてのプロジェクトのソースを持ちたくなる。IDEやソースをゲストOSに持たせるかホストOSに持たせるかは重要な要素である。
次に仮想環境を”共有”しようとするとソフトウェアライセンスの問題が発生する。LinuxやEclipseのようなフリーの環境は良いが、WindowsやVisual Studioは難しい。MSDNサブスクリプション会員同士であれば共有してよいような感じはするが、実作業を考えるとテキストエディタ(秀丸)やマージツール(AraxisMerge)など共有できないものが以外と普段の生産性に寄与していることに気がつく。プログラマーならみんなお気に入りのツールを持っているはずで、それらを全てライセンスフリーのツールで代用するというのは難しい。
さらにソフトウェア以外でもリポジトリへのアクセスなど人に属する情報は共有する仮想環境には入れられないという問題がある。コミットしないreadonlyなゲスト開発者なら良いが、コミットしたい担当者の場合、共有した仮想環境を取得したらまず、git configなり開発者固有の情報を設定してもらわないといけない。逆に今使っている仮想環境を公開しようと思うとgit configからひと通り[user]の設定を消さないといけなく仮想環境の更新の際は面倒である。
そこで仮想環境は単なる実行環境として扱い、ホストOSで開発を行うという手段が有効なのではないかと思うようになった。VMWareではホストOSにあるディレクトリをゲストOSに共有フォルダとして共有できる。Windowsの場合はUNCパスだと微妙なことがあるのでsymlinkをはったり共有フォルダにドライブレターを割り振ったりする必要があったりもするようだが。ソースコードやIDEがホストOSにあることでソースコードが分散したり、リポジトリの認証などの情報をゲストOSに置かなくても良くなる。IDE、readonlyなソースはゲストOSに置いてあげるというゲスト開発者への共存も成り立つ。
さらに実際やってみると、Webの実行環境なんかはWindowsやMacOSXで頑張ってつくるよりもLinuxな仮想環境で構築したほうがいろいろとメリットがあるのではと思ってきた。なんだかんだでWindowsやMacOSXでWebの実行環境をつくるのは簡単になってきているが、それでもLinuxに比べればまだまだだし、何より情報量が違いすぎる。あとメインストリームな環境は良いがちょっと道をそれたバージョンとかになるとLinuxと比べてWindowsやMacOSXでは一気に難易度が高くなるような感じする。
その他ではたまにしかメンテナンスしないプロジェクトの環境をいちいちメインPCで持っているのはシステムドライブの容量として勿体ないと思うようになった。SSDなら特にそう感じる。開発PCが壊れた時やOSの更新の時を考えると一から環境をつくるのはそれなりな労力になる。多くの場合ソースコードなどのデータの移行とアプリケーションの移行は別になり、後者は面倒な場合が多い、ものによってはOSを変えると動かなくなることもある。特にリリースエンジニアリングに使うビルド環境はその傾向が高いように思える。こういう場合は仮想環境でOSから別にしておいた方ががよいし、メインマシンの故障時のリスクの分散にもなると思った。
あと開発環境や実行環境の構築に特殊なシステム要件が必要でなく、かつ構築が簡単そうなものはわざわざ仮想環境にしなくてもいいかなぁと思ったりする。なんというか環境をつくるのも勉強になったりするし何でもかんでも仮想環境にして楽するのどうかなぁと。このあたりの線引きはちょっと難しいな。