Tim Griffiths
Tim Griffiths 3 February 2021

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:

  1. Getting the version of code to be deployed from source control
  2. Publishing a build of the site locally
  3. Login to databases and run any scripts to update the database
  4. Login to the web servers using something like a remote desktop client
  5. Copy and paste the new files onto the server
  6. 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.

Please login or register to add a comment.

Contribute Now!

Loving our articles? Do you have an insightful post that you want to shout about? Well, you've come to the right place! We are always looking for fresh Doughnuts to be a part of our community.

Popular Articles

See all
McDonald's: the History and Evolution of a Famous Logo

McDonald's: the History and Evolution of a Famous Logo

McDonald's logo is one of the most recognizable in the world. What does the logo of this brand mean, how did it evolve and what is the secret to the success of McDonald’s fast food network?

Anna Kuznetsova
Anna Kuznetsova 24 October 2019
Read more
How to Review a Website — A Guide for Beginners

How to Review a Website — A Guide for Beginners

Whether you're a startup or an established business, the company website is an essential element of your digital marketing strategy. The most effective sites are continually nurtured and developed in line with...

Digital Doughnut Contributor
Digital Doughnut Contributor 7 January 2020
Read more
7 reasons why social media marketing is important for your business

7 reasons why social media marketing is important for your business

Social media is quickly becoming one of the most important aspects of digital marketing, which provides incredible benefits that help reach millions of customers worldwide. And if you are not applying this profitable...

Sharron Nelson
Sharron Nelson 6 February 2018
Read more
10 Factors that Influence Customer Buying Behaviour Online

10 Factors that Influence Customer Buying Behaviour Online

Now is an era where customers take the center stags influencing business strategies across industries. No business can afford to overlook factors that could either break the customer experience or even pose a risk of...

Edward Roesch
Edward Roesch 4 June 2018
Read more
The Unintended Consequences of Brand Building on Social Media

The Unintended Consequences of Brand Building on Social Media

The rise of social media and digital connectivity in our daily lives has necessitated brands to establish a strong online presence, often relying on image-based social media platforms to engage with customers and...

Rob Sewell
Rob Sewell 9 February 2024
Read more