For years, I've been a fan of using continuous integration tools. Early on it was CruiseControl.NET and Draco with NAnt scripts, and later it was TeamCity. Even for personal projects I like to use a CI server, for many reasons, including:
- It makes sure that the software builds on a machine that isn't mine
- It remembers to stamp version numbers, use the right release/debug settings, and other steps I might forget to do, making the build more reliable
- It ensures that if the "build guy" isn't around, builds can still happen
- They provide a central dashboard for everyone to know the health of the build
Each new continuous integration server in the .NET space made it easier to achieve automated builds. But before working on Octopus Deploy, I never found a good solution to automated deployment (I think we still have a long way to go, but I like to hope we're going in the right direction).
In Visual Studio, what must amount to hundreds of man-hours have been invested into context menus and dialogs that make it easy to take code laying around on a developers machine, and to put it on a production server. Take this dialog:
I understand why tools like this are needed in Visual Studio. And these options can be used via the command line (if you have enough goats to sacrifice), so it is possible to automate them. But just as it feels wrong to rely on building on a developers machine, it feels wrong to deploy from a developers machine.
- What happens if the person who normally does the "right click and publish to production via FrontPage Server Extensions from Visual Studio" is away?
- What happens if you forget to change to release mode, or update that connection string? Did you remember to run the unit tests?
- How do you easily roll back to a previous version, or find the last good deployed version?
- How does anyone else on your team know which version is in staging, or that you're in the middle of deployment to the test environment?
That's why with Octopus, we've focused on making it easy to package applications for deployment as part of an automated build and deployment story, ideally on a build server, rather than from your development machine. Instead of wizards and dialogs and context menus, we've invested in TeamCity plugins and MSBuild extensions. We believe in encouraging our customers to follow good practices like automated builds on a build server, and making it easy for them to do so.
Of course, no good deed goes unpunished, and there's a price to pay. You can't just go from having code in Visual Studio to a production deployment with Octopus without at least having a NuGet server, and some kind of automated build process. I think it's better, but unlike wizards and context menus, there's a problem: it doesn't demo very well. It can require a significant up-front investment just to try the product.
So I think to myself: does Octopus need a wizard that can package up code you've built on your workstation, and deploy it? Should we invest our limited time in Visual Studio plugins and publishing wizards? Or, should we invest it in better build server integration? Is it too much to expect people to use the command line and build scripts to create packages?
When you first tried Octopus, one of the first steps you must have done is to create a NuGet package. How did you do it? Was it hard? Did it almost make you give up on the product before you even got to the first deployment?
What can we do to make it easier to get started with automated deployments?
