Today I'm going to talk about deployments and the importance of continuous integration š. If you are new to automated deployments, this article will hopefully give you some food for thought towards improvements that you can implement in your projects to make your life easier š§. First, if you are reading this and your deployment process involves a developer manually copying files onto the 'live' server, 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. Automating the deployment process is a proven way to ensure your website is released with fewer bugs.
When we think about automation, let us consider the non-automated way. New code is written on a local developer's PC. Once ready, the files are manually copied to a QA server. This process usually involves RDP or FTP. The work is tested and signed off by a tester and a release cut is made. A live deployment time is agreed and the code is copied onto the live server at a designated time. The release process involves a developer manually copying files onto all the live server(s). After the changes are live, a tester would check the live site by going through a set of regression tests scripts they have created to make sure key functions still work. If an error is found, either by testers or by customers, the site was rolled back. A rollback involves the developer manually copying files from a local back-up they made on each environment onto each live server and overriding the newer files. This process will force an IISRESET and users will be kicked off the website as it is restarted.
Obviously, when you read through this process it should be obvious that it isnāt great. In a load-balanced environment, what happens if the files do not copy correctly? What happens if someone makes manual tweaks on the server and the file override loses these changes. What happens if someone forgets to takes a backup of the files before overriding? Also, we have a lack of preview before go-live. 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 the tester when they run through the test 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 investment of time, you can automate things to make life easier. Saying adding a pipeline is easy, what should this change look like?
Recommended Way Of Deploying A Website
First, your deployment process shouldn't involve any manual steps, it should all be fully automated. 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 TeamCity, Octopus deploy, and Jenkins. All of these tools will do a much better job than any developer could do manually.
Next, you need to learn about deployment strategies like Green/Blue or Canary releases. Green/blue is probably the most common technique. Let us say 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.. In green/blue one of the live nodes is taken out of the cluster and bled until all connections are removed. In a CMS website, a content freeze is also often agreed upon. After the freeze is confirmed, the code is released to the bled node. Each server will also need an internal, non-public facing URL. This internal URL allows the testers to test the new code on the offline server without giving access to your customers. You can now test without impacting the live site. 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 the code is updated on it.
If you follow these two bits of advice you will have a solid deployment process and you will become a Ci/Cd legend! Happy Coding š¤
