3 ms·

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

smhinsey 13y ago
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.
manojlds 13y ago
You might be interested in a project that I have been building - https://github.com/manojlds/ydeliver https://github.com/manojlds/ydeliver
noveltyaccount 13y ago
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.

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.

manojlds 13y ago

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

noveltyaccount 13y ago

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.