Today I'm going to talk about deployments. If you are new to automated deployments then this article will hopefully give you some food for thought towards some improvements you can implement. If you read this and the old skool approaches your deployment process, then I would strongly recommend that you invest some time to configure a continuous integration process. Over the course of a few years, the time you put in now will be paid back tenfold and it will also ensure your website is released with less bugs.
The Old Skool Way Of Deploying A Website
New work is done on a local developer's PC and once ready it is manually copied over RDP onto a test server. The work is tested and signed off for release by a tester. Live deployment time is agreed and the code is released at a designated time. The release process involves a developer manually copying files onto all the live server(s). After the changes are live, someone would then test the live site by going through a set of scripts they have created to make sure key functions still work. If an error is found, either by testers, or by customers complaining that the site wasn’t working, the site was rolled back. A rollback involves the developer manually copying files from a local back-up they made on each environment. If you use sessions, users are kicked off as the website is restarted.
Obviously, when you read it, this process isn’t great. First, no sanity checking is being made on the live files before they go live. When things go wrong it’s either live customers who will spot it, or hopefully a developer or tester when they run through the scripts on the live server... but in essence, the bug has been released. This process is a bit gung ho for me.. (especially when I can be liable) and isn’t an approach I would ever recommend… to anyone… ever! Surprisingly, a lot of clients I work with still use this approach. With a small amount of time, the usual approach I would recommend would be....
Recommended Way Of Deploying A Website
First, your deployment process shouldn't involve any manual steps, it should all be fully automated (except maybe copying the files onto the live server, you may want to manually trigger the build to prevent mistakes from happening). To build a scalable website that you can change quickly, it needs to be automatic.
Fully automatic deployments will save hundreds of hours in terms of the full project life-cycle and make deployments infinitely more secure and robust in terms of rolling back etc.. Common tools to use this are team city, octopus deploy, Jenkins, all of which will do a much better job than any developer could do manually.
If you are working with traditional servers in a load-balanced environment (rather than in the cloud), each of the nodes on the live cluster is given a unique hostname, so node1.website.com, node1.website.com etc.. When we code is released to live, the night before/first thing in the morning. One of the live nodes is taken out of the cluster and bled until all connections are removed.
A content freeze is agreed with by the content team. Within this freeze period, no one saves any content within the CMS. This freeze is vital, because not all nodes will have the same code. As part of a release, if new templates are added on one node and someone used/saved this template, it will break any other node that doesn’t have the new code.
After the freeze is confirmed, the code is released to the offline mode. When the site is signed off and works, the node is added back to the load balancer and the other node is taken offline and released.