Jump to content
  • 0

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.

Link to comment
Share on other sites

1 answer to this question

Recommended Posts

  • 1

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.