[development] Active databases and development/test/production environment (was: ASP integration with Drupal?)
jp.stacey at torchbox.com
jp.stacey at torchbox.com
Fri Aug 17 09:05:26 UTC 2007
> Perhaps something hacked into the projects/devel modules to switch
> the active DB on demand would be good? A developer could use his
> own DB for development and then switch the DB to production for a
> look and feel.
Yeah, this is a possibility. I'll have a look at those modules. We're
already (as I explain below) using svn:ignore in our grand plan
(although slightly differently from Victor's suggestion), so one
possibility is for a developer to put a file on disk containing the
name of his preferred DB, set an svn:ignore on the parent directory
and switch database if that's present. That way the database can be
safely wiped without losing that switch.
> If each developer has their own directory in the sites folder, don't
> they have their own settings.php? Aren't you just trying to move the
> switching into one giant settings.php file?
Not quite: I didn't quite explain our plans for world domination
fully! We still only have a small number of client sites in Drupal (3,
well, 2.5 right now), but the plan we're still fleshing out goes as
We have a subversion repository containing "core" Drupal i.e.
everything bar the contents of sites/ . It's actually not just core:
there are tags for Drupal 5.1 and 5.2, and also tags for both of these
with our always-used modules (CCK, image etc.) Maintaining this
separate from Drupal CVS gives us control if we really, really want to
do something different from standard out-of-the-box Drupal. The sites/
directory has an svn:ignore on it, so we can dump whatever we want
under there and the "core" repository doesn't notice.
Each client site has its own *separate* subversion repository, and
this has its own settings.php file. This means that we can have e.g.
three production servers, each with a single Drupal "core" instance,
but then have e.g. ten client sites which we can roll out to any of
those production servers and handle load, traffic spikes etc. If we
know Client X is going to have a busy day, we can do DNS magic and
redeploy the sites so that Client X is on a server on its own, and the
other two servers share nine sites between them. Sites are completely
plugin-able yet under subversion.
In this situation, although each *site* has a settings.php, each
developer is checking out the same settings.php from the repository
per site. They don't want to be editing settings.php in case it gets
folded back into the repository, deployed to live and breaks it. This
means that, if two developers are working on the same development
server rather than on their desktops, then even if they work on
different physical files on the filesystem, subversion still gives
them identical settings.php, and without extra effort they will end up
sharing a database.
Having some code that would switch database based on HTTP Host is
ideal, really, as that's the main marker for Drupal to tell it which
site it has to pretend to be ;) This switching seems perfectly
natural, coming from an environment where local/live config switching
is expected, and devel/test/prod config switching is generally
This message was sent using IMP, the Internet Messaging Program.
More information about the development