Multi-version wiki farm

[James Hare]

I am currently working on setting up a wiki farm as a service.

One thing that comes to mind is version upgrades. Rather than upgrade the one MediaWiki instance and therefore all of the sites at once, I would like to be able to do upgrades in stages. One way of doing this is by having a folder per MediaWiki instance, but then the URL would change every time a new version is installed. (I do have pretty URLs set up, but only for "read" mode; other actions still require the normal URL.)

Is there a way, whether through MediaWiki or through web server-level rewrite rules, to be able to specify which version of MediaWiki a given wiki uses? At the moment, I have all wikis using a single MediaWiki instance.

[Skizzerz]

There are a few ways to go about this; the way I would personally recommend is as follows:

• Ring 1 is your internal (not public-facing) wikis. Staff wiki, staging wikis, etc.
• Ring 2 are your public-facing wikis (main wiki, any other wikis run by the farm as opposed to users).
• Ring 3 are a select few user wikis, ideally active ones where the users/admins are good about reporting issues.
• Ring 4 is everything else.

You would therefore have a directory structure as follows (assuming /var/www is your webroot):

• /var/www/ring1/w contains the wiki files for Ring 1 wikis
• /var/www/ring2/w contains the wiki files for Ring 2 wikis
• /var/www/ring3/w contains the wiki files for Ring 3 wikis
• /var/www/ring4/w contains the wiki files for Ring 4 wikis

Configure each wiki to have the appropriate DocumentRoot depending on what tier it is in your webserver config. You can move wikis between the rings by changing the DocumentRoot for their VirtualHost.

When it comes time to update, update Ring 1 first. This should be your dogfooding ring, so consider nightly (or more frequent than nightly) deployments. Train your staff to be diligent about reporting issues, or look into getting an actual QA department if you're big enough / have the funds.

If there aren't any blocking issues in Ring 1, promote it to Ring 2 on a rapid but less frequent basis. Once every week or so. This gets you wider testing as the general public is now looking at stuff, but keep in mind that issues they find may go unreported. Having robust logging and notifications in place for server errors is therefore highly recommended.

Once Ring 2 looks good, promote that to Ring 3. This means that Ring 3 is 2 weeks behind Ring 1 (Ring 1 -> Ring 2 every week/every other week, and once Ring 2 is good for a week then that old build is deployed to Ring 3 before 2 is refreshed from 1).

Finally if Ring 3 is good for a couple of weeks, deploy it to Ring 4 (so, once a month).

Note that the above strategy requires scheduled maintenance as you need to update every wiki in the ring at once since you're replacing the old files. You can work around that by staggering deployments within a ring as well, however you'll need deployment scripts to mess around with temporary RewriteRules so that upgraded wikis are redirected to new files while wikis awaiting updates stay on the old ones. You can use RewriteConds on %{HTTP_HOST} to only trigger the rules for certain domains/subdomains.