Octopus deploy at Sound Of Data

Two month ago I blogged Application Lifecycle Management (http://bloggingabout.net/blogs/dries/archive/2013/03/21/sound-of-data.aspx). I would have given regular updates on progress if it weren’t for an important project for a customer which got in the way. Or did it?

We decided to use the project as a showcase of what can be achieved when Application Lifecycle Management is firmly in place. Here’s what we did.

Development & branching

To begin with we looked at the iterative development process and the branching strategy. We decided that we should keep the Main branch stable whatever it takes, so we developed every user story in a separate branch and merged these in a sprint branch. The main branch would remain untouched until such time as the sprint branch was considered stable.

Build & packaging

We also set up a fully automated build; three of them to be exact. One for continuous integration – with a failing build notification so that the entire team would know that the build was failing and could assist in fixing it – and one that creates some packages to be released on the sprint branch and another one that creates packages for the main branch. The packages were created as described in my blog post (here and here).

The goal was ultimately that these packages would be installable on all environments (Devtest, Test, Acceptance and Production), but the sprint branch packages – the possibly unstable ones – should only be installable on DevTest. To do this we created 2 NuGet repositories (fileshares) that the build would publish to: the sprint branch would be published to our team repository and the main branch would be published to the release repository.


We decided to use Octopus Deploy for our automated deployment tool. We used the following setup to get a smooth deployment cycle. We created 2 environments, 2 project groups and 2 projects: one for the team and one for the real stuff. The team project (group) can only release to the team devtest environment and will release the sprint packages. The release packages that come from the main branch, can be published to Test, Acceptance and Production, the AppSettings that have different values between these environments are being changed by octopus using variables. Octopus does a really great job at this.


So what can we do now? We can deploy that product every time a build is finished. We do not do this automatically, because our tester, not surprisingly, does not enjoy having the devtest environment change during her tests. She’s basically in control; when she’s ready for a new test, she presses the button on the Octopus portal, a new version is deployed and she can start the next test round. (In practice we’re still pressing the button, but that’s an adoption issue…) When she gives the green light for the sprint branch, we merge into the main branch. We run the build and if it succeeds we can start to deploy to test where our tester does her thing again. We deploy to acceptance if all is still well. The same really holds true for deployment to production.

I overheard a colleague say: “Deployment has gotten from being really stressful, to being really boring; I am starting to annoy my colleagues with stupid jokes when releasing software…” Well, at least it is over very quicklyJ.

From here, we now want to go and automate the deployment of all our products. We don’t just want to write software, we want our software to be used.

Happy coding! And deploying, I guess…