development workflow

I finally decided that what I've been developing in the dbscripts module is stable and decent enough to deserve an official 1.0 release. I've written up the problem I was trying to solve with these scripts in another blog post.

So what are some improvements I've done since I first released it? Besides refactoring and cleaning up the code, I have added:

So here's my environment: I'm running Fedora on my laptop, with Apache, PHP, MySQL, Postgres and Ruby on Rails for my web development work. I then use VirtualBox to install a Windows XP virtual machine for browser compatibility testing.

Problem: How do I get my XP virtual machine (the guest) to see my Fedora's localhost (the host)?

Here's a quick bash script for automatically adding and deleting files in subversion. Don't you hate having to list each one individually? Or getting all those messages that say, "the file has already been added" when you just do svn add my/directory/*. Even more of a pain if you selectively delete a bunch of files.

I use this small little script. It's a huge time saver.

As I've mentioned before, version control with Drupal is tricky because a lot of configuration changes are stored in the database. Version control is vital because you should be maintaining multiple workspaces so you do not work on production. The last thing you want to do, then, is to make this worse by putting PHP in your nodes and blocks.

2bits wrote up a great post explaining that you should free your content of PHP. Yes! Read that! Follow it and add it to your Drupal bible.

There are virtually an unlimited amount of ways to set up a development environment, and it all depends upon your project's individual needs and your preferred workflow. Sometimes, though, it just takes experience and exposure to other ideas to figure out what would be best. So, here is a description of my development environment.

Migrating changes from development to production is particularly tricky in Drupal due to a large amount of configuration settings being stored within the database. Attendees of Drupalcon 2008 made it clear that this is a particularly annoying problem. I attended the Development / Test / Production Environments panel to learn about how the big guys (including Drupal.org itself) manage deploying their sites from one working space to the next. We were disappointed to discover that even the big guys are currently writing down all the steps to upgrade and simply performing them on the production server.

This method poses several problems due to the Human Element being involved in the entire process.

The question has come up debating if one should use an existing content management system (like Drupal) or widget (like Prototype Window), or create their own custom system from scratch.

First of all, you need to evaluate your website's feature requests, and your development team. The variables to consider are:

• Quantity of features
• Complexity of features
• Size of development team

Despite how much I love working with Drupal for my content management needs, it's largest problem is version control. A significant portion of a Drupal site's configuration lies within the database. And, despite how much I love CCK, seemingly minor changes to content types make major schema changes to the database.

All of this means that merging a development version of the site with the production site's data is complicated at best.