Hacker News Reader

Comment by jinushaun | Hacker News Reader

At my previous company, despite being a .NET shop, our main problem was not the cost--even though SQL Server is outrageous. It was the difficulty in implementing continuous integration and deployment. RDP is not a scalable solution. Implementing Chef on Windows was a major pain. The insanity of having to install VS on the build servers just to get automated builds of web apps. MS, what were you thinking with making VS a dependency for building websites?!

I know TFS offers a lot of the benefits we were looking for, but we were committed to git. (This was before they added git support in TFS) We were also burned by a lot of bad MS versions of things in the past, so were weren't eager to dip our toes into TFS.

View on HN

We've built a complete continuous deployment system with TeamCity/MSBuild that worked quite well for us. It probably took about two-three weeks to work out all the details, and now it's been running for over a year with almost no modifications.

Our Git/TeamCity/MSBuild-based build server rebuilds/upgrades the database (SQL Server), builds a web app, and a ClickOnce desktop app installer package. Everything is then copied to the target web site. At the end of each build we have a fully functional web app + downloadable desktop app (the desktop app also auto-updates if it's already running somewhere).

We use NUnit to develop unit tests, but TeamCity has it's own NUnit runner that nicely reports unit test stats and any failures.

Production deployment is slightly different - the build box pushes everything to git, and production boxes pull the latest version from git.

I did have to copy a couple of directories from Visual Studio to the build box. I guess that's the dependency everyone is talking about. I ended up with just copying a couple of things (and documenting them somewhere) rather than installing the entire Visual Studio.

One thing I didn't get to is automating C++ builds on the build box. We have some C++ dependencies. Fortunately, those almost never change, so we build them manually, commit binaries to git, and the build process picks them up from there.

All in all, it was a pretty good experience. I didn't even have to use PowerShell that much. Ordinary cmd-scripts were sufficient for most tasks. The git command line interface is quite rich, even though it can be confusing at times (but stackoverflow typically has the answers).

If you're interested in any specific items, feel free to email me.

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.

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.

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.

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

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.

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

Whats so great about TortoiseHg?

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...

Have you tried SourceTree?

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.

I have been really disappointed with MSBuild in general. I kept looking at steps in the build process and finding documents that said "you need to install Visual Studio and package XYZ onto your build server to get support for this feature".

MS does a lot of things right - C# is a fantastic language. Imho, the biggest problem with MS is the lack of the normal darwinean processes that you see out in the bazaar of open-source. MS products survive because they're tied to other MS products, so complete turds live on in spite of constant user frustration because the entire MS universe, as a whole, is good enough to keep using. But the pain points never go away, or get completely re-written by the same people with the same flaws but a whole new two-day process of learning how this new version works.

Why did you need to install VS on the build servers?

It is not needed to build web apps. My current company (a .NET web shop) has a strict rule of "no VS on the build server". I know that it's needed to build some things, like unit tests that use MSTest, the built-in Visual Studio Setup Projects, but not plain ASP.NET or ASP.NET MVC websites.

Same here. Absolutely no VS on the build server. There isn't a whole lot that VS can do that MSBuild can't do on its own.

> Why did you need to install VS on the build servers? ... It is not needed to build web apps

VS and build servers is generally considered to be a licensing issue. But if you don't have a web app, well, you still need to build it.

We have a C++ application that uses MFC. VS is required, but not anything more than VS Express (the free edition).

"But VS Express doesn't have MFC!"

Behold: License Extensions for Visual Studio 2012 and Visual Studio 2012 SDK [1]!

> If you have a validly licensed copy of such software, you may copy and distribute the unmodified object code form of the files listed below, subject to the software's License Terms and to the additional terms or conditions (if any) that are indicated. ...

> BuildServer Files for Visual Studio 2012 Ultimate, Premium and Professional editions: ...

> All files from the following folders (and all files and folders contained within these folders, recursively) ...

> Program Files\Microsoft Visual Studio 11.0\VC\

The atlmfc folder is contained within VC. So you can install VS Express on your build server and build virtually anything with it, just copy the appropriate files.

> I know that it's needed to build some things, like unit tests that use MSTest

I am fairly sure you can do all things MSTest once you've installed the client test bits [2].

[1] http://msdn.microsoft.com/en-us/vstudio/hh857605.aspx

[2] http://www.microsoft.com/en-au/download/details.aspx?id=3818...

Definitely look at OctopusDeploy.com for automated deployments. Amazing.

+ 100000

This has changed my life.

This is what I am currently using. We build changes using TeamCity on every default (live) branch commit, build the changes into a NuGet package, and use Octopus to pull in TeamCity's NuGet feed.

It can be a pain to set up large, existing projects, and I'm yet to get my SQL changes working correctly using it, but it's definitely the right way to go about it.

VS a prerequisite? In the .NET world I guess you can use TFS Server CI. You can use msbuild to take care of building websites can't you? There's always the self building IIS option but that's less rigorous of course.

I just finished my "Reengineer our CI system" sprint task!

We now run the free version of Team City on our QA-server, so it builds our ClickOnce Deployments and uploads them and it also builds our MVC4 projects and deploys them. I'm quite happy with how it works.

Reply on news.ycombinator.com