We’re starting a new series here on the Mindscape blog about tools we use to help you deliver software better. This is part one in an open ended series. This post we’re looking at…
As I’m sure every .NET developer is aware, deployment for web solutions on the .NET platform is pretty poor. This where Octopus really is like a breath of fresh air.
How does it work?
You start by setting up an Octopus server installation, it’s a simple web based system which is easily installed by a friendly setup process. After that is done the next step is to install a small agent service called a Tentacle on each target server we are intending to deploy to.
Octopus requires that you package your deployments using the NuGet package format which is simple enough to do by calling NuGet as part of your build script. To make that even easier Paul also provides an open source project called OctoPack to help automate it. Once you are creating packages you can let Octopus know about them by supplying it with a feed to your packages, this could be as simple as a local folder containing the packages.
In our case TeamCity handily provides a feed of any package artifacts that get created as part of your builds and we stamp the .nuspec file with the version number of the build so that each build gets its own package created. Octopus plays remarkably well with TeamCity.
Octopus handles deployments by first having you create a release. You then select the package you want to release and then choose where you are releasing it to. Rather than picking a specific server Octopus works with a notion of environments so you can have more than one server targetted at a given time and so you can easily manage your releases through test to production. In our case we have 2 test environments and the production environment which we release to. Kicking off a deployment causes the Octopus Server to upload the package to your target servers after which is unpacked and any installation e.g. wiring it up to a known IIS web site is done. To cater for any custom requirements Powershell scripts can be included into the deployment and executed at various points when the deployment is being run.
How does this save you time?
Deploying websites took us quite some time and I’m a little ashamed to admit we used to use the publish command in Visual Studio and manually upload a zip file of the result. Then we would back up the files and do an xcopy deploy via Remote Desktop. Yuck!
Here is what Ive noticed since we started using Octopus:
All of these time and sanity saving benefits of Octopus Deploy have already added up to be a significant amount of time saved for us. Hours. Days. Weeks.
Paul has been working on Octopus for a while and it shows. It’s streets ahead of any other deployment product we’ve seen for .NET developers. I could write quite a lot about all the different features that are now supported but it would be better if you just read them yourself: Octopus Deploy.
What’s it going to set me back?
Currently Octopus Deploy is free for one project. It then moves to $349 USD for up to 3 projects. That’s pretty inexpensive anyway you look at it given the time you will save.
We currently use Octopus Deploy for this website and our crash reporting service, Raygun.io.
This is the first in a series. If you have a fantastic time saving developer tool you think could do with some exposure, post in the comments!