It occurred to me that I should shut users out of WordPress while code deployments are taking place, particularly now that the process is going to take longer because I’ve got WP-CLI working within Bamboo, and will use it to script the movement of content, menus, and settings between instances after a code deploy. This means the site will be in limbo for a longer period of time and there will be more opportunity for things to get all screwed up during deploy.
I cribbed from the code in WP core that puts the site in maint mode during an update. The code is nothing special, and certainly hasn’t been extensively tested, but I will include it here in case it’s useful to someone else:
$instance = $argv; $maintenance_string = '< ?php $upgrading = ' . time() . '; ?>'; $maintenance_file = '/mysite_' . $instance . '/wp/.maintenance'; file_put_contents( $maintenance_file, $maintenance_string );
I deployed this code to all of the instances, although it really doesn’t need to reside in multiple places – but it’s managed by git and just part of our code base.
During a Bamboo deployment, I call this code via PHP CLI and pass in an argument with the instance to be put into maint mode:
php-cli /mysite_alpha/deploy/maintmode.php alpha
Once the deployment artifact (e.g., the updated code files) has been copied into place, I simply remove the
.maintenance file with a shell command.
To Be Done
This is all fine and good if I’m updating any code except WordPress core, but since the .maintenance file has to live in with the WordPress core install files, if I replace those files with new files then the .maintenance file will disappear.
I noodled on a couple of ways to solve this and I think what I will try is putting the WordPress core files in a separate location and symlinking to them from each instance. That way I can update WP in a location that’s not in use, set the .maintenance file, change the symlink to point to the new version and run any processes needed (like updating the database) before taking the instance out of maint mode. This will help protect against a corrupted install actually being used by any instance. If the deployment fails in the middle of copying files, it won’t matter so long as the symlink isn’t changed.
If the symlink idea works, I will also create a separate Bamboo deployment just for updating WordPress core since it really is a special case. This seems like good separation of concerns and the special steps needed only if updating WP will not be taken during more typical deploys.
Back when I was an avid Volkswagen enthusiast I found the people who went on about all the things they were gonna do to their cars pretty tiresome. Most of those ‘gonna do’ things never happened, anyway. So normally I wouldn’t post a ‘gonna do’ item to my blog but things have gotten fairly intense at work and I may be derailed from doing this if I can’t squeeze it in very early in the week. Perhaps if I have it here in writing I won’t actually forget to do it.