Let a multi armed sea creature deploy your software

den 24 november 2015

An important component when delivering software is a stable process. It is also a key if you plan to do continous delivery. At Creuna we love to try new techniques, especially ones that are powerful and easy to use.

A year ago we started to use Octopus Deploy in some of our projects to ease the process of taking newly developed features between environments fast.

Octopus Deploy is an automated deployment server that simplifies releases of .NET applications. It comes with a web based user interface where you can configure and set up different environments, what steps should be involved in a process, configure web sites, take database backups etc. You can find out more at their homepage.

I’m going to share a deployment process along with a strategy that we’re using for one of our clients: how we are perfoming deploys and ensure that there's no downtime for the end users. Below here is a simplified picture of our current environment setup.

We have a load balanced environment with one database server (i have omitted the mirroring server) and two front servers that serve content to the end users via a load balancer. With this setup we have a solid ground to build our deployment strategy on.

The deployment strategy that we are using is a well known strategy, called canary deployment. Canary deployment is a technique to reduce the risk of introducing new software versions in production by making it available on one isolated server before you move on and make it visible to everyone. Canary birds were once used in coal mines to indicate as an early warning for the miners. If the toxic gases reached a high level it would kill the birds before killing the miners, thus providing a warning to exit the tunnels immediately.

The term canary also works as an early warning in software deployment. You start by deploying your new code to one or more servers that you mark as your canary servers. In our example we have put our bird on the database server, where no users are routed.

How does this look in detail?

When you work with Octopus Deploy you define a process for your deployment. The process is built up of one or more steps. These steps are built up with PowerShell scripts performing different tasks.

In our process we start by taking backups of databases. We also make copies of them, update connection strings on the front servers to point at the temporary databases. After that the installation can start:

We start by deploying a NuGet package to the canary server. At this step we have a manually intervention step that let the responsible person confirm the new version and that it works as expected. In this part of the deployment cycle we also have managed to embedd database migrations so we don't have to do that manually after the deployment is finished.

After the canary server has been updated, a rolling deployment step is started. Rolling deployments are a pattern whereby, instead of deploying a package to all servers at once you slowly roll out the release by deploying it to each server one-by-one. That gives us the opportunity to use an identical setup for all of the front servers. When this step is executed it will automatically update the connection string on the servers back to the original databases as well.

For our overall process we are using a feature called promotions. Promotions are a defined journey that a release package takes. In our process we have defined that the release first has to be installed on our internal development environment, before it can be deployed to the staging environment. When it has been approved by the customer on the staging environment we can promote it to production. This ensure us that there are no untested versions deployed to production.

Use Octopus Deploy!

If you can automate it, you should. Octopus Deploy is an easy and powerful tool that simplifies your release process. As far as I've used it I can say that I am impressed how great it works. Some of the reasons for us beginning to use a tool to automate our deployments was that we wanted

  • To minimize time spent on boring work like doing deployments manually
  • Anybody in the team to be able to perform a release


When we have our NuGet Package ready to be shipped, we are few clicks away nowadays. Our QA-manager is now our deployment manager. It is no longer needed to be a developer to do that job. It is also very nice to rely on a tool instead of manually deploying, as we all have done.