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

[Steven Jones]

Genius,
I'd never thought about using SVN and drupal in that way.

Indeed some database switching would be awesome. might have to have a closer
look at all this. Let me know if you get anywhere yourself!

On 17/08/07, jp.stacey at torchbox.com <jp.stacey at torchbox.com> wrote:
>
> 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.
>
>


-- 
Regards
Steven Jones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070817/430d8b48/attachment.htm