A multi-developer shop may prefer to let their developers work on the same sites on a single development server using a single database.

When having many developers working on many different sites, it is preferable that a developer can create a new site or start working on an existing site that some other developer already created without intervention from "root". Likewise it would be preferable if new developers (e.g. short-term employees) can start working on a site
without too much initial setup and intervention from "root".

It is preferable that developers do not have a local copy of Drupal so that security updates easily can be rolled out by the server administrator.

It is assumed that a developer has his own checkout of the site code using Subversion or CVS.

Implementation

Using a wild card DNS entry and Apache rewrite rules it should be possible to allow multiple users to work on multiple sites without having to add individual VirtualHost entries. Hostnames should be rule-based, e.g. <developer>.<site>.drupal5.example.com.

If the hostname is e.g. john.foosite.drupal5.example.com, this should map to a central copy of Drupal, e.g. /usr/share/drupal5. However, when looking for a site, Drupal should look in ~john/drupal5/sites/ in addition to /usr/share/drupal5/sites/.

Drupal should look for modules in ~john/drupal5/sites/foosite.drupal5.example.com/modules and
~john/drupal5/sites/all/modules prior to looking in /usr/share/drupal5/sites/foosite.drupal5.example.com/modules and /usr/share/drupal5/modules. Likewise for themes, theme engines etc.

The administrator should be able to choose whether ~/drupal5 is one big Subversion/CVS module, or whether individual modules exist for each module/theme/theme engine. In case of individual modules, the developer
should not be required to pull the modules from Subversion/CVS that he is not going to be working on, e.g. he should be able to work on a site that uses a specific custom-made theme engine without having to checkout
the theme engine. If the whole of ~/drupal5 is one big module, it is easy for developers to keep their local copy up-to-date, and in that case a local copy is acceptable.

All developers should be able to use the same database for a specific site, i.e. any paths saved in the database should work independently of whether the user has checked out a specific module or not.

Resources

For inspiration, see http://www.garfieldtech.com/blog/drupal-dev-server.

Comments

aclight’s picture

aclight commented

Hm....I'm not sure how appropriate this is for a GHOP task. It seems like something that wouldn't be that useful for a vast majority of Drupal users. Anyway, the proposal is not written according to the guidelines at http://code.google.com/p/google-highly-open-participation-drupal/wiki/Ho...

Specifically, there is no deliverable section. What should the student create? A Drupal module? A set of scripts?

Plus, I think the task is pretty vague as far as the implementation goals.

dman’s picture

dman commented

It's a good idea, and worth a handbook page guide ... but only by someone who wanted it, and had the ability to execute it, and actually worked with the set-up in the wild with a team for a while to solve the issues.

Me, I HAVE a similar setup,
Wildcard DNS on my dev server, mapping back to a single Drupal install.
That gets split off into any existing /sites/* subdirectory (copied by hand from a sites/template/ dir)
My template/settings.php includes 

$db_prefix = preg_replace('/[^a-zA-Z1-9]/g', '_', basename(conf_path()) ) .'_';

to enable these auto-instantiated sites just get created via prefixing ... Or I do the DB creation by hand. Depends on if it's a demo or a client job.
My files/ dir is directed to sit inside the site dir.
I use a custom profile that configures most of the rest on first startup.

Anyway.
YES, it can be done, but only by someone who's worked in real-world teams, needed to use CVS for real reasons, installed and created multiple Apache configs on multi platforms, has root to the DNS config on their LAN , and done a lot of Drupal installs, upgrades and synchs.
(setting up bind and rewiring my router the first time was non-trivial)

In other words - no way is it a student task! The concepts (although very good in the OP) are pretty hard to grok for someone who hasn't actually seen what can happen with teamwork snarl-ups.

How about just chopping it right down to a handbook page on Apache wildcards -> multisite drupal. That's possible to get someone's head around, although even DNS alone is a bit deep.

Paragraph 2&3 would be bad, dangerous changes to Drupal core. Not likely. A better solution may be available with symlinks.
I don't even understand the last paragraph.

I appreciate that it would be an interesting project to get done. I just don't think a newbie, student or outsider can write up a usable "best practice" guide.

c960657’s picture

c960657 commented

I don't even understand the last paragraph.

Let me elaborate: The "system" table contains paths to modules, e.g. sites/john.foosite.drupal5.example.com/modules/bar.module. The paths saved in the database should not contain developer-specific paths (i.e. not the username of the developer who initially enabled the module).

(setting up bind and rewiring my router the first time was non-trivial)

AFAIK most DNS hosting services allow their customers to specify a wildcard entry for their domain. It is easy to set up, assuming your DNS host supports it. You do not need to run your own DNS server.

But I agree that this kind of task may not be that well suited for GHOP.

cwgordon7’s picture

cwgordon7 commented

My feedback:

I don't think this is a good GHOP task for two reasons:

(1) For most of the starting students, this task is big, scary, and unapproachable. For most of the experienced students, this task is boring, relatively inconsequential, with a lot of effort spent for little gain.

(2) There really aren't any good deliverables that we can ask for. A handbook page would likely not be able to go into detail enough on this huge documentation task; it would be extremely hard to explain in a video.

-cwgordon7

aclight’s picture

aclight commented
Status: Active » Closed (won't fix)

It sounds like several people agree that while this task would be great to have, it probably isn't right for a GHOP task.