By Vidarls on

I've come to the conclusion that I have dug quite a hole for myself;
Currently I am responsible for maintaining Drupal sites for six customers, and keeping up with security upgrades are allready becoming quite a chore.
To complicate things, the Drupal versions range from 4.7 to 6, and I do all maintanace manually, but at least I do module updates through CVS.
The sites are run from one codebase per version.

What are the best practices for maintaining multiple Drupalsites. Can anything be automated.

Does anyone have any advice or magic solutions.

Comments

dwadson’s picture

dwadson commented

I made some comments in http://drupal.org/node/396196 about how I use Subversion to update site code.

Vidarls’s picture

Vidarls commented

I can see how this could help me maintain my own custom modules, but I fail to understand how using SVN will help keeping my drupal cores and contrib modules up to date.

dwadson’s picture

dwadson commented

You probably need to understand how vendor branches work to fully comprehend how it helps with contrib modules.

Basically, in my "Drupal" repo, I have a folder for a module like CCK, for example. Within that folder, are various version of the module as they are released, the most recent one being tagged as "current":

/6.x/modules/cck
  - cck-6.x-2.2
  - cck-6.x-2.3
  - current -> cck-6.x-2.3

In my site, I checkout "current" from the Drupal repo using Piston:

piston import http://path/to/repo/6.x/modules/cck/current \ sites/all/modules/cck

When a new version of CCK is released, I use svn_load_dirs.pl to add it to my Drupal repo and tag it as "current":

/6.x/modules/cck
  - cck-6.x-2.2
  - cck-6.x-2.3
  - cck-6.x-2.4
  - current -> cck-6.x-2.4

Now, on my site, Piston is used to update the "current" version of CCK that I had originally imported (6.x-2.3) to the most: piston update sites/modules/cck.

Vidarls’s picture

Vidarls commented

I fail to see how this is any better than just checking out the drupal module from cvs, as long as I do not modify any of the code myself.
To me it seems like just another step, meaning more work, not less.

Drupalace-1’s picture

Drupalace-1 commented

I suppose the easiest way is to bring all your Drupal sites up to the same (most recent) version of Drupal, and run them all off a single installation. You could then have modules like Update Status enabled for just one site; when that site informs you of a needed update, perform the needed actions, and run update.php for all sites.

Easy as can be, though with an obvious drawback: if you make such an infrastructure update for one site, you have to plan to update all of them at once. And if there are reasons why you *need* to use different versions of modules, or even different versions of Drupal, for different sites, then of course it's no good.

Still, I would put Drupal's multisite capabilities to use and run as few separate installations as you can. Is there a reason why you can't bring those 4.x or 5.x sites up to a modern version?