Opinion April 5, 2011

ASP.NET Deployment Needs To Be Fixed

I deploy Tekpub, on average, 3-5 times a week. This used to scare me every single time I did it - for various reasons: no rollbacks, I'd overwrite some of Avery's changes, I'd forget something. Imma go ahead and say it: ASP.NET Deployment is a joke.

This Should Be a Solved Problem.

What’s your deployment scenario? I’ll take a swing and see if I’m right:

Aside from the BuildServer (more on that in a bit), each of these methods involves a varying mix of:

  • Egregious use of XML
  • Archaic and often insecure transmission protocols
  • The complete inability to rollback
  • Exclusion of source control
  • Unnecessary inclusion of a server administrator
  • The need to remote in to your server on a routine basis (as some will point out – SSH is sort of the same thing. But it’s not…)

Now you might have invested enough time and pain to get this to work for you – sort of like walking around on your hands (if you chopped off your feet).

But here’s what I don’t understand: Microsoft owns the server, they own the database, they own the platform, and they own the IDE. One would think that, just possibly, this would be a solved thing.

It’s not. It’s just plain sad.

It’s more than a little shocking to see the state of deployment in ASP.NET. If you think I haven’t tried to be constructive on this in the past, well you’d be wrong about that. 

Well OK Let’s Be Constructive

Just copy Capistrano. It doesn’t do everything perfectly, that’s for sure – and there are many folks who will point out some of it’s faults. Prop it up against MSDeploy, however, and I think we can probably agree that one of these tools was created by developers with opposable thumbs.

Is Capistrano perfect? No – but it’s a great place to start and if the team is capable of creating NuGet as a bit of a port of RubyGems – then hey use Cap as your blueprint for a deployment tool that actually works.

So what’s the deal with Capistrano? Here’s the skinny:

  1. It pulls from source securely. There is no “push”.
  2. It uses intelligent directory structuring. Some things you don’t want to overwrite – log files, config bits, etc. These are aliased to a “shared” folder.
  3. It uses SSH rather than FTP/HTTP/WebDAV/NAMBLA. This means I can do all kinds of operations on my server – which are needed when deploying.
  4. Because it uses source, it will always use the latest commits – which means that you won’t be stepping all over your team-member’s code. You know – the code they push in a panic using XCOPY because their last deployment cratered the site?
  5. Rollbacks. If you screw up your deployment – just roll it back. Your site’s up, you can fix, all’s good.
  6. Database updates. Make a change to your database in development? You can push those changes to your production box and have Capistrano run those migrations for you.
  7. Task-hooks. Capistrano has hooks that you can hook into – things like “after deployment” in which you tell it to remove the oldest versions of your site.

Stay With Me

You might be wondering: “what’s wrong with using a Build Server to deploy your site? Well if you try to use Microsoft stuff completely you’ll end up doing something exciting like installing Visual Studio on your Build Box.

Now you could use CruiseControl and a mishmash of other products as this article suggests:

You can setup continuous integration and automated deployment for your web application using CruiseControl.NET, Subversion, MSBuild and Robocopy. I will show you how you can automatically build the entire solution, email build report to developers and QA, deploy latest code in IIS all using CruiseControl.NET every N minutes

It’s a pretty handy set of suggestions – but consider what we’re stepping through here:

  • A build server that we have to maintain
  • A configuration file we need to decipher
  • MSBuild
  • Robocopy

It’s always good to have a Build Server – but how do you go about checking in if you don’t want to deploy? Short answer: you don’t. Or you write more code to get around this.

How do you rollback your deployment? You don’t. Or you write more code to get around this.

These things are doable, but they aren’t optimal. Build Server hooks are not a substitute for effective deployment. It’s overly-complex for such a simple scenario.

Summary

This is a solved thing in Rails. So much so that many gems come with “hooks” pre-built for Capistrano deployment:

  • Delayed Job can be added to your deploy.rb so that it automatically stops/restarts running job threads
  • Whenever will automatically write out to your crontab on deployment
  • Hoptoad will notify whomever you wish when your app has been deployed, and will track who is deploying what, when
  • New Relic (the Rails monitoring service) will track and monitor your deployments, and let you know if you screwed up.

Capistrano is just using the mechanisms of SSH and Source Control. Heroku built an entire business on SSH and Source Control and is, right now, the model of efficiency and awesomeness when it comes to pushing your app live.

And yes I know all about AppHarbor. They’re awesome, but they’re not a deployment solution.