Use your imagination

Thursday, May 25, 2006

Speeding up time to development with virtual servers

I recently started development on a personal .net project and wanted to get my development supporting infrastructure in place as quickly as possible. On my last corporate project where I was the tech team lead I planned for and used VMWare virtual servers for all of our development environment. This lead to a fairly large cost savings due to not having to purchase 4 brand new servers that the project required. Thinking of my success there I decided to download the VMWare Player, which is freely available from the VMWare site, and first use it to create a code repository. I went with VMWare because I know it is easy to use and performs rather well, however there are other Virtual Server options freely available such as Xen or Microsoft's VM solution.

I decided to use Subversion as my repository. This will be my first use of Subversion as I've mostly used CVS in the past. Subversion requires a *nix OS to run the server upon, so I searched on VMWare's image gallery to find one or more Linux flavors to try. I ended up first trying, mostly out of curiosity, a fairly new distro which comes from rPath. They keep a VMWare image of their distro with all LAMP (Linux, Apache, MySql, PHP-Perl) applications pre-installed. I knew this would help speed up my time to development. I also noticed the LAMP image included an older version (1.2.3) of Subversion in it.

Their package management system, named Conary, is supposed to help resolve conflicts and difficulties in updating, but I did run into a problem when trying to update the subversion "trove" to the newest they have available (1.3.0-1-1). First when trying to update with the command conary update subversion=conary.rpath.com@rpl:devel I got some "Could not resolve dependencies" messages. I stumbled around and finally found the two troves, "openldap" and "db", that contained the dependencies I needed. After updating these two troves I again tried to update the subversion trove and had a conflict with the mod_dav_svn trove, so I added the command line switch to force replacement of the files in that trove. After all of this was done I installed TortoiseSVN on my development system and tried connecting to SVN. I forgot to mention that I had to change the VMWare Player Ethernet setting to Bridge mode in order to pickup an IP from my LAN router and connect to the instance from outside the VM.

I was able to connect and import a new repository in only about 30 minutes time. A lot faster than installing a Linux flavor from scratch along with all of the needed components. I will also now be able to move and use this repository server image on any of my machines and back it up quite easily with environment and all intact. Some other plans for this server are to use it to create a development blog and wiki since all of the base components to support this are already installed.

I also tried a different VMWare image containing Fedora Core 5, but I'm not sure I like it as much since it is a full blown Linux install, even though having a GUI sometimes is nice;) It was also just as easy to get up and running on this by first downloading the image I found in the VMWare gallery and after running through some first time use setup I opened a terminal and issued the yum install subversion command.

I think using Virtual Server instances for development infrastructure is not only a huge time saver, but it also has many other advantages like portability, ease of environment replication, and well defined server job boundaries.


Post a Comment

<< Home