4 ms·

RDP isn't a scalable solution. I'd recommend PowerShell for all that. For the build server, you just needs msbuild which i think is available on the .net SDK.

by adrr 13y ago

RDP isn't a scalable solution. I'd recommend PowerShell for all that. For the build server, you just needs msbuild which i think is available on the .net SDK. For CI, i've used TeamCity in the past which worked well. Staying away from TFS is a good a decision. On windows boxes i recommend mercurial because tortoiseHG is so nice, really miss it ever since i moved to developing full time on a mac.

noveltyaccount 13y ago
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.
- skeletonjelly 13y ago
  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.
- jimmcslim 13y ago
  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 http://technet.microsoft.com/en-us/library/dn249912.aspx
tr4656 13y ago
Whats so great about TortoiseHg?
- cpayne 13y ago
  I've tried a few times to use Mercurial from the command line and just can't get my head around it. TortoiseHG takes all that pain away by visually displaying what has changed / the different builds & branches. Merging is so much easier...
  - voltagex_ 13y ago
    Have you tried SourceTree?
  - w0rd-driven 13y ago
    Hg's command-line tools are pretty awkward. TortoiseHg, in especially the latter versions where the interface is unified into one big dialog, the workflow is exceptional. Everything I needed was at my fingertips at all times. I've since drank the git koolaid after being forced to at work but after the introduction of git-flow I'll find it very hard to switch again. I know hg-flow exists but again due to Hg's awkward command-line or specifically how it is in the TortoiseHg window I would likely need a significant workflow boost to switch. Though it would be a good exercise to try to take a lot of how I work now and see how much I can bend TortoiseHg to that. TortoiseGit specifically has a few holes where no UI exists and you have to use the command line but those are very infrequent. TortoiseHg and Hg in general seems way more user friendly to me but Git is definitely more powerful as you have access to all the knobs to completely trash a repository easily.

by adrr 13y ago

noveltyaccount 13y ago

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.

skeletonjelly 13y ago
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.
jimmcslim 13y ago
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 http://technet.microsoft.com/en-us/library/dn249912.aspx

tr4656 13y ago

Whats so great about TortoiseHg?

cpayne 13y ago
I've tried a few times to use Mercurial from the command line and just can't get my head around it. TortoiseHG takes all that pain away by visually displaying what has changed / the different builds & branches. Merging is so much easier...
- voltagex_ 13y ago
  Have you tried SourceTree?
- w0rd-driven 13y ago
  Hg's command-line tools are pretty awkward. TortoiseHg, in especially the latter versions where the interface is unified into one big dialog, the workflow is exceptional. Everything I needed was at my fingertips at all times. I've since drank the git koolaid after being forced to at work but after the introduction of git-flow I'll find it very hard to switch again. I know hg-flow exists but again due to Hg's awkward command-line or specifically how it is in the TortoiseHg window I would likely need a significant workflow boost to switch. Though it would be a good exercise to try to take a lot of how I work now and see how much I can bend TortoiseHg to that. TortoiseGit specifically has a few holes where no UI exists and you have to use the command line but those are very infrequent. TortoiseHg and Hg in general seems way more user friendly to me but Git is definitely more powerful as you have access to all the knobs to completely trash a repository easily.