Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
Today (Nov 19th, 2007) we released Visual Studio and Visual Studio Team System (including Team Foundation Server) 2008. It may seem a bit anti-climactic after all of the CTPs and Betas along the way, however, it's a thrill to have it done, broadly available and fully supported. You can go to http://www.microsoft.com/vstudio to find the download link. You can also read http://blogs.msdn.com/somasegar for more information.
This has really been a pivotal product cycle for us. Microsoft has had a reputation for shipping product much later than originally anticipated. With our 2008 release, we embarked upon a significant effort to begin to erase this reputation. As part of this we underwent significant changes in our engineering process - pushing quality sooner, being more deliberate about how complete a feature must be before it is published into the "mainline" code base, and becoming much more transparent with our project metrics and checkpoints. As part of this we made a substantial effort to adopt Team System internally - using things like the test frameworks, static analysis, code coverage and more to help ensure the quality of the product was high early in the process. Perhaps the biggest tooling change was the adoption of Team Foundation Server. We relied heavily on it to provide a clear picture of the state of the project at all times and to help us make adjustments when things went awry.
A few weeks ago, I did a little archeology in my saved mail to figure out exactly what the schedule was at the very beginning and when and why it changed along the way and by how much. The net result is that the 2008 wave of developer products shipped within about a 10% margin of error from the very first bottoms up schedule that was assembled by the various participating teams. This is a stunning accomplishment. Managing a project of this magnitude is an amazingly difficult task. I'm very proud of what we accomplished.
Back to the release itself... Those of us who blog actively about VS were asked to talk about our favorite features. Of course everyone is somewhat colored by what they work on (me being no exception :)). I have a hard time choosing between 2 features. The first is the Team Build improvements in Team Foundation Server- including Continuous Integration, Scheduled builds, Drop management and more. The improvements to Team build make setting up and managing your automated builds a breeze. The second feature that I'm really excited about is .NET Framework cross targeting. This allows VS 2008 to build applications for .NET 3.5, .NET 3.0 or .NET 2.0. This is something I've been wanting ever since we released .NET 1.1. I hate the fact that the tools have been strongly coupled to a version of the Framework and that to take advantage of the cool new tooling features you've had to upgrade your applications to a new version of the Framework - which frequently is not practical. While the user experience around this in VS 2008 is not perfect, I believe we've set a pattern that will be followed in subsequent VS releases and the user experience will get better and better.
I'm really excited about the release. I know TFS 2008 is going to be a terrific upgrade. There are some great features. Performance and reliability are improved. And installation and operations are dramatically improved. As you may know, we've already started developing the next version and are eager to hear your feedback on what you'd like to see done after you've had a chance to fully get your arms around this version. It's still a long way off so there should be plenty of time for you to get your feedback in.
We are also already planning Service Pack 1. No, that does not mean that we shipped a ton of bugs - 2008 was probably the highest quality release I've seen. It means that we've turned another new leaf and committed to shipping a service pack within 6 to 12 months after every major release. There are always things you'll find that you want fixed. And there are always new releases of other products for which we have to do work to support. This commitment around service packs means we will not turn a blind eye to the products we've already shipped to focus only on the next product we are building. Instead, we will maintain a balance - making sure the current product everyone is using stays fresh and relevant while we also work on the next product. As you take stock of VS 2008, let us know what you think needs to be changed. Maybe we can get it into SP1 and maybe we can get it into the next major version.
Enjoy, I'm looking forward to your feedback.