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:

1. Manual deployments are far more likely to go wrong
2. They distract our developers from producing new work
3. They take time to do
4. As they take time, they end up being performed less frequently
5. They permit, and even encourage developers to add one-off, manual steps – these are easily missed if someone else performs that deployment
6. 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:

1. Errors in the scripts could cause some deployment steps to fail silently
2. It took a long time to set up a new deployment environment
3. 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.
4. We could only deploy to local network machines – we couldn’t connect to Azure Web Apps or client servers.

Steady improvement

Over time and many iterations, the process has matured to become:

1. Code is committed to (dev platform) GitHub
2. TeamCity picks up the change:
   • It builds the code
   • creates a package of the output (such as a compiled website with all transform files) and
   • pushes the package to Octopus Deploy.
3. 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:

1. It really is a one-click deployment to live, with zero clicks for development and release candidates
2. It offers increased visibility of what has been deployed, and the detail of any error that occurred
3. It has greatly reduced deployment errors
4. It’s caught build issues, such as Entity Framework database migration issues, earlier in the process
5. It has allowed us to create Azure web app environments on the fly, and to automatically configure them as we need them
6. 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.

Featured image: Duncan Hall/Flickr, Creative Commons