To update or not to update
There’s a sweet contentment knowing that a system is fully up to date and patched, but how uncomfortable it soon becomes when you find out there’s a new update or patch – leading to the nagging question of if / when to go through the grief of updating.
On the one hand, you know you should apply updates as soon as you can to get any potential benefit of new features, bugfixes or even improved security and performance – but anyone who has been around long enough will know that even the simplest patch can upset an otherwise stable system and be a royal pain to resolve.
That leads to the temptation to procrastinate and put off updating systems until it can’t be avoided any longer, but the longer updates are left the more they build up, and the worse the process of updating becomes – again you may hear the sigh of bitter experience?
I’m not just talking about applications like Wordpress and Drupal, or the dreaded Windows Update – there are so many constant reminders from all sorts of systems to ‘update now?’ And I’m talking about minor updates rather than the biggies like Vista -> Windows 7 or Drupal 6 -> Drupal 7 – those you have a choice, but minor updates you really don’t, it’s more a matter of ‘when’ than ‘if.
Here is a summary the guidelines that I try and stick to:
Have a regular ‘maintenance period’ – Accept that maintenance is a fact of life, and schedule an appropriate amount of time at least monthly to review logs, apply updates and other housekeeping tasks to maintain a healthy system. Of course this implies that the more systems you look after, the more time will be spent in maintenance, but that cannot be avoided – without tlc systems tend to ask for your attention when it’s not so convenient!
Don’t do updates on a Friday afternoon – As tempting as it may be to slip this task in at the end of the week if your ‘proper work’ allows, it’s tempting fate and if you have problems with an update you might not have enough time to resolve it, or you might shortcut testing and not spot an issue until Monday. Make sure you have set enough time aside to do it properly, and you’re in the right frame of mind.
Design your system to be maintained – when carrying out initial installation and configuration, think ahead to how you are going to apply and test updates and patches, and migrate changes between environments. Good decisions at the start make life so much easier six months down the line. Documentation and good naming conventions are key. And of course as part of your deployment there was a test plan that can be used to validate updates?
Prepare and maintain a documented maintenance procedure – It makes the task much less daunting to know that you have a ‘script’ worked out rather than having to keep re-inventing the wheel. Wikis are ideal for the purpose as they’re easy to create and maintain. Anything you have to spend time figuring out so that next time you don’t have to struggle to remember it, or work it out again. If you find information that’s wrong or missing, fix it, and keep documentation updated as your system evolves.
Read the release notes - try to get an understanding of what the update or patch you’re about to apply will change so you can analyse potential risks and identify any mitigating measures you might take, and to also identify what testing you can do to satisfy yourself all’s OK afterwards.
Once you start – don’t stop until you finish – it’s probably worse half applying updates than not applying them, and even harder to do maintenance next time. So no distractions, and remember the ‘not on Friday afternoon’ rule.
Pat yourself on the back afterwards – it’s a necessary job, so make sure you get your due reward. If you’re doing this for someone else (a client) make sure they appreciate the effort it takes, and don’t be apologetic about taking the time to do it properly. Few people notice a well running system, but you soon get shouted as when it goes titsup, so sleep well in the knowledge that all is right with the world again and you have done a proper job!








