I previously tried helping a software team deploy their .Net app on Windows VMs. As a Linux engineer, I was shocked at the lack of built-in remote deployment/management options, especially those able to be automated. FTP and SMB shares, the built-in options, are not appropriate for the Internet. Why does Windows Server not ship with an SSH/SFTP server? I ended up deploying a Windows build of OpenSSH just to get remote access parity with Linux servers. Unless things have changed recently, Windows really needs a better out-of-the-box application deployment story.
There's a built in deployment method called "msdeploy" that makes it super easy to deploy a website. It's either one click from visual studio, or highly scriptable from the command line. My company hasn't manually deployed code in years, it's one click in team city to build and deploy.
nice post. we do something similar, except using MS Web Deploy. We also explored Octopus but wanted an agentless mechanism. We're also keeping our eye on Desired State Configuration
Yep, I think the nice thing about using purpose-specific tools like OctopusDeploy is that it lets you escape Cloud/Platform specific deployment tools making it easier to switch between cloud providers if you want to.
i.e You can save money later by moving off the Cloud once you have a better idea what capacity you need to handle your load, and then deploy to better value hosting providers like http://www.hetzner.de
Octopus looks neat. But I'm still not sold on NuGet as a deployment package. We also use Web Deploy, and our build outputs a zip file and deploy script per app. They're executed/deployed via a master deploy script.
Is there much benefit to using Octopus as opposed to an extra MsBuild step that does a publish?
I've had TeamCity set up to do continuous integration/deployment without much pain so I was wondering if I'm missing out on something or it's just a different way to the deployment/publish step?
You can easily configure different things of IIS/ASP.NET like Port Bindings, App Domains, Config Transforms, SSL Sites, etc. We also use it to bundle and deploy out-of-project artefacts.
One nice feature is that it keeps all your releases and can easily redeploy a previous known working configuration.
Don't forget rollback. That has saved us a number of times.
One of the things I like about Octopus is rather than deploy over the existing instance it deploys a version alongside. Then if everything is hunky-dory with the deployment process it simply tweaks IIS to point at the new deloyment folder. I don't believe that MSDeploy does that. I think it just overwrites the existing source. Also, can MSDeploy deploy to multiple servers?
Anyway, Octopus is very neat and tidy. We also recycle app pools and restart windows services using Powershell scripts as deployments out of Octopus for some legacy apps that don't support distributed caching and the cache is stale. It's quick an dirty but it works.
We've found AWS has a richer ecosystem for the things we want to use, e.g. We're using PostgreSQL RDS for our managed RDBMS.
It's also nice to be able to point your deployments to any server instead of being coupled to Cloud-specfic tooling. i.e. If Cloud costs ever get out of hand we can point to the better value and performing dedicated hosts like hetzner, with minimal migration effort.
I assume you could just deploy to an Azure/Rackspace/Other VM or to a physical server rather than an AWS VM if you decided to, there's nothing PAAS specific here. Is that correct?
We also use FluentMigrator.net to migrate databases automatically throughout our environments: https://github.com/schambers/fluentmigrator
You can also use Octopus to run Powershell scripts. You can deploy one off tasks or re-runable tasks to your entire server farm with one click.
I can recommend https://twitter.com/DevOpsGuys to help you get this setup.