An excerpt from http://www.sitepoint.com/ditch-scheduled-maintenance/, by Shaumik Daityari
This article was sponsored by PagerDuty. Thank you for supporting the sponsors who make SitePoint possible.
Scheduled website maintenance is the planned maintenance of a service, usually requiring a significant amount of time and manpower, as well as downtime for your service. It’s the internet equivalent of sending your car away for a tune up. The problem is, web apps are definitely not cars.
Let’s face it: no one loves scheduled maintenance — neither the customers nor the developers. It’s time-consuming, usually comes on a weekend, and potentially costs the company performing the maintenance money. Even if you perform your maintenance on a Sunday night in the United States, that’s early morning the next day in India, for example, so those users are affected by your outage.
Webmasters “schedule” such maintenance tasks to make major changes to websites. The only reason they do so even after knowing the potential effects is to avoid the interference they would face if their service was still working. Imagine a car mechanic trying to fix an engine when it’s still running.
Fortunately, modern development methods mean things have changed. This post will talk about ways to ditch scheduled maintenance and find a way to fix bugs in real time, without affecting a single user! Initially daunting, it is very achievable with proper planning and execution strategies.
##Continuous Deployment — A World Without Scheduled Maintenance
Let’s start at the beginning and talk about the goal of scheduled maintenance. This is usually the time when you roll out major changes to your product — be it solving bugs or adding features. Usually, you’ll perform a bunch of changes during one session of maintenance to make the most of the downtime.
The other, better way of making these changes is simple — in real time. This is called continuous deployment. As soon as you identify a bug, you assign it to a developer to be solved. Once the bug has been rectified, you merge it with your main code base. It sounds pretty simple, but there are a few more steps involved.
##Maintain a Staging Server
Many organizations maintain a staging server with a dummy database — one that acts as a link between your local machine and the main server. The primary motive of the staging server is to test how the changes would look to an end user. You’ll first preview the changes on the staging server and if you are satisfied with the changes, you’ll make them appear on the main server.
Access to the staging server must be restricted and this could be achieved by hosting it on an uncommon sub-domain (something other than “staging.yoursite.com”).
##Automated Testing
You should ensure a proper testing framework (which includes tests like unit tests and integration tests) that a given fix should pass through before being merged with the main code base. This is important because the fix itself could introduce a new bug, which could lead to downtime. In many organizations, this testing is automated — your code is merged on the main server only when it has passed all the specified tests.
The idea here is to ensure that any bit of code that you add doesn’t end up breaking something.