It’s always nice to see something you have spent time developing being used in production.
A while ago I read an excellent blog post from Timothy Fitz called Continuous Deployment at IMVU: Doing the impossible fifty times a day, that got me started on trying to improve the way we deploy our websites at UKFast but just as important – being able to roll back to a previous version at the drop of a hat.
We had a few requirements such as, hook into current systems, deploy code with near zero downtime, run some post deploy commands, stop deploying on error and keep an archive of old deployments for simple roll back amongst other things.
As you’ve probably gathered by the title, we run Subversion as our version system, it works well as a standalone but that’s never enough for us at UKFast. The system that was developed so far has achieved everything that we need, new or existing sites are deployed usually within 30 seconds but that depends on the size of them, the freshly deployed code is activated online without any loss of service to visitors to the site which is probably one of the best features about this system. It also means that roll backs are done transparently and due to another feature, archives, depending on the (user configurable) number of archived versions we keep, we can roll back to a previous version almost instantaneously as the code is already deployed and ready to go – if we need to go back further past the archived version then a checkout is done on the old version.
Now once a site is deployed, that typically wouldn’t be the end of it. If someone had tried to perform the update manually then it most likely wouldn’t be case of just FTPing up the new website, for one, we usually have some heavy customisation on folder structure, permissions or just because we want something different. So the system needs to cope for this as well, it will allow users to issue post deploy commands from a predetermined list of allowed options. This has so far covered us from all the usual requests our web developers usually ask for and without have to give them a ssh shell!
In the event that any errors are detected at any point the deployment is halted and the user performing the update is notified, no need to roll code back in anyway as the new version hasn’t even gone live yet.
This system has meant we can stop using ssh / ftp accounts for website management, determine fine granular access to developers and mainly, allow us to update our websites at any stage of the day, knowing that it won’t impact site visitors and if it does, then we have a roll back process that takes us 10 seconds to perform and the site will be restored.
Unfortunately the way in a lot of our systems work means I can’t discuss it on an open blog, competitors might be watching. But if anyone wants to pick my brains then by all means, get in touch.