[support] multiple sites on same install was: Re: Upgrade to Drupal 5?

[Ivan Sergio Borgonovo]

On Wed, 17 Oct 2007 13:11:16 +1300
Anton <anton.list at gmail.com> wrote:

> On 17/10/2007, Ivan Sergio Borgonovo <mail at webthatworks.it> wrote:
> > Modules in different sites tend to have different versions. Adding
> > sites to the same code base may mitigate these problems.

> I use the svn:externals property for that (developing modules
> branches outside the main Drupal core codebase). More write up here:
> 
> http://drupal.org/node/118936

OK. But nothing to do with multi-site... that's a different trick ;)

So different projects are just a collection of links to your drupal
core repo, contrib modules and your own work (modules + themes).

How do you plug in core and contrib?
You'd have your own repo cos you can't commit to the original repo.
If you've to tweak core or contrib, how do you diff with upstream
updates?
You plug it in somewhere with a different tag and diff with the
previous then you apply the tweaks to the new imported version, you
open a new branch for all your projects, make the links to the new
components, test.
Repeat for all the projects... maybe a bit faster cos you already
tested in one place...

Do you have someone in charge just to keep versions in sync or the
person that modify a module, is responsible for upgrading all the
projects? Who/when do you upgrade contrib modules?

Start to sound interesting if you deployed a lot of automation... and
nothing should stop you to forget to link projects to newer version,
but at least you'll have a trace of what you did for other projects
that were upgraded.

Tricky things like modifying your own modules "on place" can be risky
cos you'll modify all your projects.
You should branch the module, modify one project to link to the new
version, test it, change the link of all the others...
The workflow should require a lot of discipline.

There is still too much manual work in programming ;) wasn't it all
about automation?

what did you simplify in your svn layout? what is the exact workflow?
including the launch of scripts?

> > mmm let me understand... you share *all* the codebase including
> > modules etc... with the exception of settings... just to edit the
> > production settings before checkout and let it land on the server
> > as you need it and not as on your local copy?

> All settings live in the repo - we don't exclude anything from the
> repo.

Yep, but you'll still have to change production settings *and* dev
settings I suppose just for the DB connection.

> No editing of production settings required. The production settings
> live in the repo under the production sites directory (eg
> /sites/example.com). Our deployment script does an svn export into a
> temp directory, then scps the files to the production server.

Why 2 steps? tmp -> scp?

thx


-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it