April Seattle Drupal User Group

I have the same issue, my company has members in 3 states and multiple long duration clients. Our solution is a little involved and has evolved over the years to be something that works pretty well. We just scale it down for smaller jobs, but the core remains the same.

Each developer has their own local environment, usually a VirtualBox configuration that matches the target environment. This allows us to test both Drupal and any server back-end processes of which we may have many. Each developer uses the tools they prefer to access their environment, which is tied to the source code management system. Every client project gets its own virtual environment for each developer involved. In nearly all cases we are coding both in and out of Drupal so this works quite well.

When code is pushed from the developer's environment it goes to our shared TRUNK. This shared environment is usually configured to update itself on any trunk updates (we also can do a manual update triggered by a special module). As we are in nearly constant communication with each other (Skype IM) this works better than it sounds. Then we make any settings changes that a normal Drupal update.php would not do (we avoid manual changes like the plague). This helps document changes so we can build a top-to-bottom manual for configuring the site. Developers can easily miss documenting a step on their local environment and that mistake shows up here very quickly.

After Trunk is stable and we all sign off on it the code is committed a branch. The branch triggers yet another update on on ALPHA server which then begins a Drupal auto-update as well as some core fix-up logic for permissions and such. This is often what we use for client reviews and feedback. From here it can go to a QA, BETA, RC and RELEASE server (depending on client needs and complexities) all using different branches which allow for parallel development and patching.

From there we can synchronize with a client source code system (which can be rather complicated) and/or package the site into its final location.

All sane database changes occur in modules. While I like CCK and friends it is horrible for tracking changes over time on a commercial site. We tend to avoid CCK and Views except for emergency fixes or for smaller sites that do not have a formal QA process (actually we use those modules but mostly internally). In most cases we need to be able to reliably replicate and rebuild a site from scratch, often fully automated, for the clients internal QA and validation teams.

If we need a database filled with data that is done with a separate process so that the QA cycle is sane and reproducible. The devel module, snapshot databases and custom scripts manage this.

This is may be a lot more complicated than you need. The trick was tying our Trunk and Other Drupal site to the source code library and then triggering an update on a commit. We use Redmine for our tickets and tracking and a Perl script triggered by the source code system that causes the other server to update. The Perl script handles enabling new modules, disabling modules we deprecated, performing a Drupal Update and other actions, mostly via Drush.