Automated Deployments And Why Brands Need Them
When working on a new website build, some of the most frustrating tasks that use up budget originate from the IT team and come under the category of setup. They can suck days, even weeks, from a project but offer no visible features or benefit to the end user. Worse still, they often need to come at the start of a project which for people wanting to see a design turn into a webpage just feels like a delay and lack of progress.
So, what are automated deployments and why are they worth it?
When a change or new feature is ready to be built for a site, it will have been turned into a specification and handed over to a development team to build. The developers will then write some code and test it.
At some point, that work needs to get from their machine to the server(s) it runs on so that other people like Quality Assurance (QA) can see it without using the devs machine. Typically, there will be three server environments set up for a website:
- Dev / Test – an environment used by the developers and QA to build, test and refactor new features and fixes.
- UAT / Staging – an environment used by the website owners / stakeholders that the features have been deployed to for review and approval before they are deployed into production.
- Production – the live website that is accessible over the internet.
In a manual deployment setup, the developer is responsible for copying the website into each of these environments. This will generally involve:
- Getting the version of code to be deployed from source control
- Publishing a build of the site locally
- Login to databases and run any scripts to update the database
- Login to the web servers using something like a remote desktop client
- Copy and paste the new files onto the server
- Make a record that the deployment has been completed and what it entailed
Each of these steps is prone to human error, while the entire process is quite lengthy. Some parts are just waiting for a code publish to complete or a file copy to finish. For iterating work into QA, this cannot only make QA fails for minor things costly to fix, but also result in bundling more and more changes together to cut down the number of releases. This will then reduce the flow of work feeding into QA and slow the pace at which features can be developed and released.
A Better Way
Automated deployments quite simply take all these manual steps and automate them with a few bonuses on top. By doing this, brands remove all the elements of human error and are left with consistent results each time.
There’s two parts to an automated pipeline: the first is build and the second is release.
The build part relates to the first two steps of a manual process. Brands need to get the code from source control and then publish it. Once this is done, the build can be assigned a release number. By automating it, brands also ensured that the build happens the same way each time. At this point brands can also start detecting build failures and include some automated testing to pick up on errors before even involving QA.
The release part relates to the remaining steps. Copying files and running scripts now becomes one large script that won’t miss a step. In addition, brands now have build numbers and can see which build is on each environment and only promote the one they want to the next environment.
By promoting builds rather than repeating the whole build process again, brands also ensure the build going to production is the exact same thing that was tested on QA and then reviewed on UAT. With some clever integrations, brands can also automate release notes to say what was included in each of the releases.
Degrees of Automation
As well as automating the deployment of code, brands can automate the entire server setup through the use or ARM templates in Azure. Different levels of automated testing can be implemented from very low code coverage to very high.
Automation could also extend to include load balancers for green / blue deployments where zero downtime of the site is achieved by using multiple production servers and switching between them while files are being copied.
Two terms I deliberately haven’t used in this article are Continuous Integration (CI) and Continuous Delivery (CD) because although automated deployments form part of achieving them they are not the same thing and it’s worth knowing how they differ.
Continuous Integration relates to the build part of the automated setup and aims to deal with issues arising from multiple developers working on a project. When more than one developer works on a copy of a website locally, both sets are changing in different ways to what is contained within source control.
The longer this goes on for, the bigger the differences get and the harder it will become to merge again. Continuous Integration advocates shortening the gaps between merges to as short a time as possible. By having automated tools in place to run a build whenever this happens, issues can be identified at the earliest.
Continuous Delivery relates to the release aspect of the automated setup and aims to be constantly delivering / deploying updates to a solution as fast as possible. By doing this, deployments become trivial and smaller updates are delivered at a much faster pace rather than being queued for one big release. Automation helps make this a reality by removing many of the manual time-consuming tasks that are repetitive.
Automated deployments do come with an upfront cost to setup. This is however offset in time savings throughout a project lifecycle. In addition to lowering costs, automated deployments improve the overall reliability of a deployment and most significantly achieve continuous integration and delivery.