The Drupal development list has been sharing Drupal development server setup secrets lately (try saying that five times fast), so I figured I'd toss mine out there. And since knowing me it wouldn't be short, I figured I'd blog it instead of just posting it in email. :-) Here, then, is the development environment we've set up for Palantir.net.
Several people have noted that each developer on a project has their own complete copy of a site, including database. We actually take the opposite approach. Everyone has their own install, but the database and files directory are shared specifically so that we don't need to worry about synchronization issues.
We have a single development server in-house, on which everyone has an account. They also have a sandbox, with a subdirectory corresponding to each project we have active. Each user/project is dynamically mapped to its own domain name, so we don't have subdirectory pathing issues to worry about.
We also have a Subversion repository with our in-house Drupal 5 install profile. It's a stock Drupal 5 (now 5.2) download, an install profile with a few extra key modules (CCK, Views, and a half-dozen others), a sites-dist directory instead of sites, a slightly modified Zen theme in sites-dist/default/themes, and a stub for a site-specific module in sites-dist/default/modules.
When we setup a new project (say fooinc), we have a script I wrote that does the following:
- Create a new repository fooinc.
- Export from the main Drupal5 repository to garfield/sandbox/fooinc.
- svn add all of the new files to the fooinc repository.
- Create a blank database fooinc.
- Move sites-dist/ to sites/.
- Create a shared files directory /shared/files/fooinc and symlink it to sites/default/files.
- Set permissions on settings.php and sites/default/files as needed.
I (or whoever is setting up the project) can then just run the Drupal install script and select our install profile, which does the extra setup we need, and then hit svn commit. yes, we even commit the settings.php file, because the database is shared and we don't need to set a base path.
Anyone else joining the project, then, just runs another script which:
- Checks out from the fooinc repository to lastname/sandbox/fooinc.
- Symlink sites/default/files to the shared files directory for that project.
- There is no step 3.
The advantage of this setup is that we can have a new project created and ready to go in, usually, under a minute, and new people can join the project in under 30 seconds (give or take checkout time if we have large modules). The shared database generally doesn't cause us a problem, either. Since so much of modern Drupal site setup isn't coding but configuration (CCK fields, Views, node settings, comment settings, Actions, etc.), having to merge the databases would be a nightmare. This way we have a single shared system. In practice it's very rare that we break anything on someone else's dev environment by changing a site config in the database. Far less common than a conflict when checking in a file that two people have been working on (which happens sometimes even with the best commit practices).
The other advantage is ease of upgrading. When Drupal 5.2 was released, we simply had to upgrade our base repository. Then one person on each project runs another script (yay for automation!) that just exports from that base repository over the files in that project. Because all site-specific code is kept to the sites/ directory (this is why Drupal people always tell you do to that!), and the base repository has a sites-dist instead, we don't lose anything. Simply run the update.php script, commit, and you're done. (For 5.2 we also needed to merge the settings.php changes, but that's rare.) Everyone else just does an update as usual. It works for updating modules in the install profile, too.
We have some tweaks planned in the future for this setup, mostly in the install profile itself. I keep wondering if I should be using svn vendor branches and other advanced magic, but so far I haven't needed to and this has worked well enough for our needs.
Hopefully this entry will prove helpful to someone else setting up their own multi-developer environment. And if you have suggestions on how it could be improved, I'm interested in those, too!