Automating deployment: what we do, and how we benefit

At Red River we spend a lot of time examining our own tools and processes, and ensuring that they’re as efficient and productive as possible. One area we have been incrementally improving over the last few years is our automated deployment process, where our objective is to remove any manual steps in deploying a piece of code to any environment.

There are a number of reasons why this is a good investment of our time:

Manual deployments are far more likely to go wrong

They distract our developers from producing new work

They take time to do

As they take time, they end up being performed less frequently

They permit, and even encourage developers to add one-off, manual steps – these are easily missed if someone else performs that deployment

Automated deployments can be scheduled

Our automated process has evolved since we first started. It began with the Java-based build-management server TeamCity, building the project and running custom PowerShell scripts to deploy the code to pre-existing locations. This did hit some of the points above but it had its drawbacks:

Errors in the scripts could cause some deployment steps to fail silently

It took a long time to set up a new deployment environment

The building of the code was tightly tied to deploying it – there wasn’t a clean or clear enough separation between building, packaging and releasing an artefact or package.

We could only deploy to local network machines – we couldn’t connect to Azure Web Apps or client servers.

Octopus receives the request to create a new release for the newly pushed package (artefact):

It will ensure the environment is setup correctly

deploy the app to that environment and

inform Slack if it was successful or not and where it was deployed to.

This a very high-level overview of the automated software deployment process, and obviously there are lots of variations for different projects, customers and type of applications. The main benefits we have found from the newer process are:

It really is a one-click deployment to live, with zero clicks for development and release candidates

It offers increased visibility of what has been deployed, and the detail of any error that occurred

It has allowed us to create Azure web app environments on the fly, and to automatically configure them as we need them

It’s greatly reduced the time it takes us to set up a new deployment pipeline

The process is evolving as we continue to innovate and improve it, but it has come a long way to something that’s clearly far more effective. We and our clients benefit from it every day – a great return on the time we’ve invested in trying to optimise it.