All blog entries reflect the opinions of the author and have not been expressly endorsed by the Ivan Allen College of Liberal Arts or the Georgia Institute of Technology.
There are a few lessons that I learned before I came to the Ivan Allen College that have benefited me greatly in my first few months with the college. One of them is that it's far easier to do web development if you set up your own LAMP server and host all of your development sites in one place.
My LAMP (Linux, Apache, MySQL, PHP) server is a very straightforward setup with virtual hosting enabled. I use a standardized directory tree structure where each virtual host gets its own directory with subdirectories for its httpdocs and logs. Anything private that goes along with that particular website gets its own directory off of that main directory, thus keeping everything for a website in one place. A series of directory aliases (soft links) simplifies the task of navigating amongst all of these sites.
I have a special subdomain under the iac.gatech.edu domain just for web development, and every site gets a short CNAME in that subdomain that points to the LAMP server. This makes it easy to keep track of all the sites I'm working on and lets every site be at the root directory of its hosting space, simulating the site's eventual production hosting space as closely as possible.
The real key to making all of this work in a highly efficient manner is the automation I have done. I keep a repository of Drupal modules (and Drupal cores) on this LAMP server, and have scripts built to let me push any module or core update out to any site on the server without any manual intervention. This saves much time not only when applying updates, but also when I'm building out a site and need to add a module that I know is already in my repository. Scripted deployment of updates is definitely the safest way to go, as it ensures that every time you push an update, you're carrying out all needed steps, so there's no having to worry about remembering to set filesystem permissions and user/group ownerships.
While I can't reach out to all the different hosting spaces where my production sites live quite so easily, I have been trying to bring a level of automation to them. With sites in OIT Web Hosting, I have scripts setup in /private now that are based on my LAMP server scripts, automating the deployment of modules and core updates that I have dropped into the /private directory. This slowly, but surely moves me towards my goal of having a standard upgrade process that works much the same on every website, even if the underlying upgrade scripts have to be a little different to accommodate site and hosting differences.
Since I love automation and the time savings it brings, I've actually automated 90+% of the process of setting up a new virtual Drupal host on my LAMP server. I have one script that does all of the Apache setup and directory creation for a new virtual host, and a second script that automatically sets up the mySQL database and user account for the host. After they finish running, I can unpack a custom IAC Drupal distribution that I've built (more on that in a future post), go to the website in a browser, and have Drupal installed in just a few clicks, since everything I can possibly automate in the Drupal setup has been automated. The entire process can take as little as about three minutes to build a working virtual host with a fully installed Drupal instance -- so fast that my one bottleneck is just waiting for the campus DNS system to push out the virtual host's new CNAME.
Whether or not you ever use such a system for production Drupal site management, it's certainly a great time saver for a development server. While I haven't done this yet, it would be perfectly feasible for me to be sitting in a meeting where the group decides they want a new Drupal website, and before the meeting adjourns I could have the development site up and running for them to look at.