The company I’m currently working for is called Digital People, a creative agency based in London. We make exclusively Drupal-based sites, which normally showcase the results of market research, and increasingly act as portals into the research departments of large companies.

We develop using a Subversion-based workflow. Here’s a great article by Nick Sergeant which closely approximates our current development practices.

At this point, it should be noted that the codebase we both have checked out is from ’trunk’. We always develop on trunk. That is, of course, until we have a reason to branch off into separate branches. This is a smaller project, however, so we simply build on trunk for now.

How to handle multiple developers sharing a DB:

Every once in a while, we’ll tell each other to run updates to grab the latest code from trunk. This is especially important when adding new modules. If you need to add a new module into trunk, download (or CVS checkout) the module into your codebase, then add and commit to trunk. Before you enable the module, tell Pete to run an update on his codebase (he’ll probably have no clue what you’re talking about). We don’t want to go about enabling a module, resulting in the database change, and have Mr. Pete access the site with the now enabled module in the database, but no module files to support it.

Bringing changes back from the live environment:

When we’re ready to begin a new ‘development cycle’, we clone the production database, and completely dump and rebuild the development database with the production database.

One major difference being that we don’t check our “files” directory into subversion, as it often contains video and other large files.