Ale, music and enjoying life.
Working with one other developer on a greenfield project we had no CI in place. Somehow over the course of a couple of sprints (and mainly off plan) I managed to get TeamCity configured and Octopus deploy to push out the 3 main apps we were building to Dev and 2 Test VMs.
I’d had some experience with TeamCity in the past so was up and running with build configurations pretty quickly. I was unaware of TeamCity’s Nuget server support and spent a bit of time working with that to publish artifacts from the build (earlier blog post here) . This was a great move as we had a class library which became a dependency for just about every other app we were building.
That done, we still had no way of pushing the build apps out to our dev/test servers. I toyed with the idea of powershell scripting but thought this could get quite messy. Plus the VM boxes (although reachable via IP) were not on our domain.
I’d read about Octopus deploy and thought it would be worth spending an hour or 2 investigating a proof of concept. Within a couple of hours I had the Octopus Server sat on a VM and the client/agents “Tentacles” listening on the deployment VM servers (dev and 2 test boxes).
From there it was a case of configuring an “environment”, a machine and roles. I went down the route of firstly, specifying the Nuget server then configuring the Octopus Server with a new Project based on one of the Test VMs – specifying the package Id to push and adding a Custom install location (rather than the “C:OctopusApps” standard location). Within around 30 mins I was watching files being deployed out to the Test VM as expected. Incredibly easy. It becomes even easier if you install the Nuget “Octopack” package into your Projects that you wish to deploy out and configure accordingly through TeamCity (this saves an extra build step of “Nuget Pack”).
There’s plenty of helpful vids over at http://octopusdeploy.com/learn/videos