Hacker News Reader

Comment by noveltyaccount | Hacker News Reader

Yes. PowerShell, PowerShell, PowerShell a thousand times. I think that every .NET developer should be functional in it. PowerShell can do everything they already know from the .NET BCL, AND run every command line tool they've ever used, AND every server administration task you can imagine. And it's extensible with .NET. I've personally witnessed some pretty awesome one-click deployments with PowerShell, including to Azure with zero-downtime using the MS-supported cmdlets.

View on HN

The new PowerShell Desired State Configuration in PowerShell 4.0 (Windows 8.1) looks interesting... almost a bit Chef-like?

http://technet.microsoft.com/en-us/library/dn249912.aspx

Can you share anything about that one click (nothing to do with one-click™ I'm sure) deployment?

We have a number of one-click deployments running in TeamCity. It's honestly very straightforward. If you're deploying to Azure you can use either the Powershell or node.js libraries to talk to their API. We use powershell. Basically, we compile using msbuild, package the artifacts into an Azure package, and deploy it via the API. Doing zero-downtime deploys to Azure is a matter of how you use the API. You can substitute EC2, another cloud, or traditional hosting and while the tools and APIs get progressively less powerful, it's all doable. At the simplest level you may just use msdeploy as your "API."

I'm a huge believer in this kind of automation. We make extensive use of TeamCity to drive it. In addition to builds, automated tests, and deployments, we also use it for release promotion and doing other housekeeping tasks like cleaning up data from QA environments, restoring testing databases, etc.

It's a lot like what @smhinsey described. Team City was our CI platform (could be TFS), applied XML transformations using PowerShell for the target environment (I'd probably use the .config patching nowadays), built it using msbuild, which output a cloud deploy package, and using the Azure cmdlets deployed that package to the Staging slot, started it, waited for it to respond to a HTTP request, and then performed a VIP swap.

We did have to take an outage for breaking schema changes. Publish to Staging slot stopped, stop the Prod slot, upgrade the database, start Staging, swap the VIP. Total outage was as long as it took to start the VM, a minute or two. We used code-first database with NHibernate.

You might be interested in a project that I have been building - https://github.com/manojlds/ydeliver

Reply on news.ycombinator.com