[development] Active databases and development/test/production environment (was: ASP integration with Drupal?)

[jp.stacey at torchbox.com]

Earnie:

> 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.

Steven:

> 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  
follows.

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  
desirable.

Cheers,
J-P


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.