Microsoft takes on GitHub with cloudy Team Foundation Service

Builds are important

In any agile shop Continuous Integration is going to critical to maintaining a healthy codebase. So the build it self is very critical. To do CI you need to build on every check-in and run all unit tests so you can reject the check in on any test failure. Effectively making broken builds a thing of the past. This reduces a huge amount of churn and expense. Any seasoned dev will know that the later you find a bug in the process the more expensive it gets.

If you're still doing old-style water-fall this won't be as important as you're probably still suffering through broken builds and regression test passes.

@asdf: handing over source code

Seems you're contradicting yourself: you correctly emphasize the importance of source code security (and not handing it over to third parties on a whim) but only complain about the build service?

What do you think TFS does? If it doesn't get your source code, that white-looking summary screen will be even whiter!

protecting source access is as important to MS as it is to us

time was when financial accounts were considered too confidential for computer systems, then a decade later it was considered too confidential for shared (switched) cable, then a decade later too confidential for outsourced data-centres and contract DBA.. today we know better.. We know how to match confidentiality with controls and Chinese walls.

I've loaded my companies source code into the tfspreview.com, and have less worries than I had with my SVN hosted with Webfusion. MS pays all the cost of Chinese walls to stop me suing them for stealing my code.

I'm impressed with TFS and like the combination of all continuous integration components together.. And may even use the continuous deployment with VM too test-case management

Re: Poor bastards

There are many worse things...

In the early days of Symbian we used MSVC6 (ie Visual Studio from 1998) with some whacky build rules to slave the oddball Symbian build chain. It was fast, productive, and pleasant; people quickly hacked up datatype viewers for custom types when debugging on the Windows-based emulator.

But it was produced by a competitor and they weren't going to do us any future favours, So for "strategic reasons" we switched to Metrowerks CodeWarrior, owned by a shareholder (Motorola). It was slower, clumsier, notably far less stable, had silly eternally-unfixed bugs like periodically the debugger plugin would leave a handle open on the binary, forcing exit & relaunch to be able to link a new build. And even after years it still couldn't display a couple of the fundamental descriptor (string-like) classes correctly; memory hex dumps were the way to go.

But then CW was recognised as a dead-end (and its owner was keen to shed the Symbian support since the lucrative developer base never materialised) so we switched to a customisation of Eclipse. And across several years this got steadily better, adding mostly-working on-device debugging, fixing some of the more glaring editor issues (though symbol lookup remained erratic to the end, and it marked every template used as a source error after the first hundred or so). But it remained a big strange mess, a stew where things were added but never removed (the difference between an editor window, a text editor window, and a C/C++ editor window? who knows, but when assigning shortcut keys you needed to pick the right one) and just never reached the sheer liveability of the twelve-year-old VC6.

Moral (if there is one): tools matter, and while VS ain't no Emacs it's very far from hell