Figuring out How to Implement a Drupal Development Environment

I have been working with Drupal for different reasons since about September. While it's in my opinion the best content management system I have ever worked with so far; there are a lot of complex situations that need to be considered when working with it. I have spent the entire weekend trying to figure out the best practices for setting up a development environment that will allow optimal deployment and updatability. My other two primary concerns are; scalability and performance once deployed. I wanted to elaborate on the process I have settled on and am working on implementing for my certain situation. This process will probably only work for developers or sysadmins.

My Development Setup

I develop cross platform applications using Windows, specifically XP. That probably rules out a lot of you, but what I mention may be easier on other platforms. I have an older spare XP machine that most of this resides on.

Virtualization

The main place my Drupal installations sit are inside of Virtualbox virtual machines. I am using Virtualbox because I haven't ever been a big fan of VMWare when using it at work. I also want the ability to quickly start up a fresh Drupal installation for experimentation and have some portability across systems. On any system it always takes at least an hour to setup Apache, PHP, then the database, then Drupal, then all the base modules like views and cck...etc.

Host OS

The host operating system I am running Drupal on is Ubuntu Linux 10.04 LTS 32 bit server version. I originally started with the desktop version because I wanted drag and drop functionality of a UI when installing modules for Drupal, but that was not practical once I setup Mercury which I will explain below. My old XP machine that runs virtualbox does not have a 64bit OS, so that's why I'm using the 32bit version. The reason I am using Ubuntu is because of the package manager and also a drupal setup called Mercury (I think the new name for it is Pantheon). You do not need to sign up for whatever their site says.

Mercury

When doing research on performance optimization, I already had heard a lot about tools like Memcached, but wasn't familiar with other techniques until watching presentations on Drupal Performance Enhancement and Drupal Cloud Computing from Drupal-Con 2009 on Drupalize.me. Apparently there is a still-in-development methodology of configuring Drupal and particular host OS's for the best performance and ready cloud integration on "AWS, Rackspace, RackspaceCloud and Linode". Developing in an environment that is already configured for high performance with the ability to deploy to cloud services, really seems like a win for me; which is why I am going with Mercury even though there is still a pretty big learning curve.

When setting up Mercury, you basically take a fresh Ubuntu installation, then configure the system with some minimal software that then takes over and configures your system for you. The main component of Mercury is the BCFG2 configuration manager. If you want to learn more about BCFG2, there is a rce-podcast about it. The Mercury configuration will wipe out your GUI version of Ubuntu once it finishes configuration, so you might as well start with the command line version and get used to it. I have been following the Mercury 1.1beta guide so far.

Drupal Updates Through Version Control

Every professional that I have seen or read about Drupal deployment, talks themselves into a storm about how you must use version control. The methodology they use is something similar to this.

There is one central server that contains the version control masters, lets say a SVN server instance. All developers and production instances run SVN clients. As changes are made in the development environment, programmers check those changes into the master SVN server instance. This version can then be checked out by test instances, or production instances.

There are two major constraints to this methodology in that you can't version control the master database, and you can't version control multimedia files. These must be handled through separate channels.

Personally I haven't ever learned how to properly use cvs, svn, or git but I guess its time. From what I have heard, git is the grand daddy of all the version control systems right now and addresses some complex user permission problems that occur in svn. However, all of the tutorials I have found with Drupal mention svn, so that's what I will setup in my development environment. I don't have anywhere good to make a svn repository server right now, so it will bet setup on the same Windows XP machine that is running Virtualbox.

I came across a Windows based SVN Server called VisualSVN that I am going to try out for the server instance. I have had a command line svn client for working with open source projects for a long time that I will continue to use.

Wrapping Up

This all probably seems like a lot of over-kill for just fooling around; but a few days seems like a small price to pay when dealing with complex architecture issues such as scalability and performance down the road.