Well, I’m back. Yes, I feel terrible that it’s been what 18 months since I last posted here. All I can say is that I’m going to try to do better. Somehow in the daily crush of emergencies I just never seem to find the time to sit down and write something for my blog. I’m grateful that people like Rob Caron and Buck Hodges are around and do find the time (there are others who do a great job too but those two stick out in my mind). Since we’ve recently released Team Foundation Server Beta 3, I’ve been spending a fair amount of time trolling the forums (http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=22). I recently saw a post asking for a list of improvements between Beta 2 and Beta 3. It seemed like great fodder for a blog topic so here I go. It has been 7 months between Beta 2 and Beta 3 so there’s no way I can capture all of the improvements we have made. I’ll try to highlight the major changes but I can think of dozens of things I’m omitting and I’m sure there are dozens more that I’m not thinking of. Team Foundation Server Proxy We implemented a proxy designed to improve performance of Team Foundation Server over slow network connections. You might use the proxy by installing it in a remote office that is connected by a T1 to “headquarters” where the Team Foundation Server is. For V1 it improves performance by caching version control files in the remote office such that everyone there can access them at local LAN speeds from the proxy rather than having to go back to “headquarters” over the T1 for every file. Our performance testing so far (there’s more remaining) shows anywhere from about a 5X to 30X improvement using the proxy depending upon the connection speed and the file sizes (bigger files show a larger improvement). In future versions we will be leveraging the proxy to cache more data “at the edge”. Performance enhancements We have made substantial performance improvements all around – client and server. I’ll talk about specific notable ones in other sections but the improvements are not limited to those that I call out. Security work As has become standard practice at Microsoft, we had our “Security milestone”. In the security milestone, the entire team spend a significant amount of time (in our case about a month) focusing on security and privacy issues. We review our Threat models – parts of the spec that describe all of the possible ways the product could be attacked or expose information inappropriately. We do extensive code reviews. We also do “penetration testing” where team member attempt to create attacks that violate the security of the system. We made quite a lot of improvements during our security milestone. Bug fixes Of course we made tons of bug fixes. I don’t know the number but it was thousands. We completed our test plans and automated thousands of test cases too. Overall the product quality is significantly higher. Globalization/Localization We did a lot of work and testing to support globalization and localization in Beta 3. Beta 2 was not localized but Beta 3 will be localized into several languages. Installation improvements We’ve known for over a year now that installation was our gremlin. It’s been too hard to install the product since the beginning. We made a ton of improvements. We reduced our dependencies – for example we eliminated our use of Active Directory Application Mode (ADAM) because it was proving to be a source of installation problems. We also added a new setup “pre-requisite checker” that examines many aspects of the computer and pre-requisite software to ensure that setup can be successful and the user can have some clue of what they need to change before they get all the way to the end and discover that it doesn’t work. This is an area that we are not done with – one of the very few DCRs (design change requests) we have between Beta 3 and RTM is to add more checks to verify more aspects of pre-requisites. We believe that Beta 3 is already dramatically better. I’m watching the newsgroups carefully to see how people are faring and I’m very sorry to see that some people are still struggling (SharePoint seems to be the biggest problem so far). In addition to newsgroup feeback, we have instrumented the setup process thoroughly and can collect statistical and diagnostic data from anyone who chooses to upload that data to us. I’ve asked for all of this data to be analyzed and I’m going to have a review of it next week. We’ll learn from all the problems and make the Release Candidate even better. In addition to installation “quality” improvements, we’ve enabled more installation scenarios. Of course, single server is working again. We’ve also tested it on Win2K domains (in addition to Win2K3 domains). Further, TFS can now be installed on a machine that is in a workgroup so you don’t have to be on a domain any more. All of these kinds of changes ought to generally make it easier for people to get the system up and running. MSF Process guidance and help We’ve added tons of content to both help and Process Guidance. In addition we’ve significantly refined them to make them easier to use and respond to customer feedback. Many people have been waiting to see our CMMI process guidance and I’m happy to say that we’ve got it ready for a first look but I’m sad to say that much of it didn’t make it into the initial Beta 3 release. We are looking at putting it in the Beta 3 Refresh in a couple of weeks or posting it on the web for people to download. Regardless we are looking forward to getting some feedback on that. Improved admin/ops We’ve learned a lot about the Admin and Ops needs from our own use of our dogfood server. As a result we did a bunch of work to improve it. We moved all of the mutable TFS data into SQL server to greatly simplify our backup story. We’ve done work and testing to ensure that we have a reasonable availability story – Clustering on the SQL Server and warm stand-by for the application tier. We also created a utility to help with things like changing service accounts and passwords, changing the application tier or data tier machine names, etc. Lastly we improved information that is available for monitoring and capacity planning. Version Control Performance – I hate to say it but the performance of version control in the IDE in Beta 2 was really bad. We discovered it too late before Beta 2 to fix it because the fixes involved some significant changes. Part of the reason we missed it was that we were not using it internally sufficiently. All of the developers and most of the testers were using the command line and not the IDE. The reason for this has to do with limited side by side support of the VS IDE for interim builds. We don’t support (very well) having a “known good” daily build IDE installed on your machine and the “current build” that you are developing. We addressed this between Beta 2 and Beta 3 so that everyone was using the IDE and we focused in finding and fixing all the performance problems. The result is that the experience is dramatically better in Beta 3. > 2GB files – In Beta 3 we added support for files bigger than 2 gigabytes. We now support files with lengths of up to 64 bits. OK, we haven’t actually tested a file that big :). We’ve tested some very large ones and I don’t think disk sizes will be big enough over the next few years to support files beyond what we can support. Conflict resolution – We made substantial improvements in our UI for resolving conflicts. Build improvements Command-line tools – We implemented a command line build tool that allows you to kick off builds, delete builds, etc. This command line tool can be used to implement scheduled builds, rolling builds, continuous integration, etc. Improved UI – We made substantial improvements in our Build UI. Both the wizard for creating build config files and the reports for reviewing builds are improved. Office integration improvements Better field mapping with MS Project – We improved the mapping of fields between work item tracking and MS Project (and generally improved the usability in that scenario). For example we mapped the “Assigned to” field to the MS Project “Resource”. This way assigning a task to someone in Project and importing it into TFS will result in a work item assigned to that person. Long text fields in Excel – We added the ability to include long test fields (like description) into Excel. This makes reviewing and editing work items in Excel a much better experience. Dramatic performance improvements – Our poor Beta 2 performance of Version Control in the IDE was rivaled only by our poor performance of managing anything but small lists in Excel or Project. A list of hundreds of items used to take minutes to publish or synchronize in Beta 2. Now it takes seconds. Query bound lists – In Beta 2 we only had what we call ID bound lists in Excel. An Id bound list is a list that is bound to a specific set of work items. When it is refreshed those work items are updated. However, if I wanted a list of work items assigned to me, I could create that and when I later refreshed it those work items would be updated. However any new work items assigned to me would not get added. I would have to go through the “work item picker” to explicitly add them to the list. This is fine for managing explicit lists that really aren’t based on a query but not for other. In Beta 3 we have added a feature we call “query bound lists” that will save the query used to create a list and rerun that query on refresh so that items no longer matching the query will be removed and new items matching it will be added. Improved conflict resolution – We improve the general usability around work item conflict resolutions when items are changed in the database and the office application (possibly when off-line) at the same time. Warehouse Substantial performance improvements – Another area of big performance improvements. Some reports would take 20 or 30 minutes to execute in Beta 2. Most reports now execute in seconds. That said, reporting is still an area we are focusing on between Beta 2 and Beta 3. We expect further significant performance improvements between Beta 3 and RC 1. Improved usability – We did some cube restructuring, improved the field names, removed some unneeded ones, etc. The cube is now dramatically easier to use in Excel. Some of our Beta 3 -> RC 1 improvements will make this even better. Work Item Tracking – For some reason I can’t think of a lot of work item tracking improvements we made since Beta 2. I think that’s partially because it worked reasonably well in Beta 2 and most of the improvements we made were for office integration or the warehouse and I covered those under those headings. None-the-less, here’s a few things I can think of. Improved syncing – Many of you may have seen latency problems in Beta 2 where you’d add a user to the system and it might be an hour before you could actually assign a work item to them. We switched many of our server data synchronization mechanisms from polling to event based. This improved the timeliness of propagating changes and reduced the background load on the server because syncs only happen when something changes. Keep query results up to data – We fixed it so that when you edit a work item, other views of it change. In Beta 2, if I changed the assigned to and closed the work item, the query results would still have the old assigned to and was confusing. UI performance – Rendering, validation and navigating work items (particularly in results view) are substantially snappier now. Power Toys – What is a “Power Toy”. We are using this to describe tools that we have built and want to make available to customers but are not “part of the product”. We have not worked out the exact support policy around them but most are likely to be unsupported, “as is” licenses. If you find them useful, please use them. If you don’t post something on our forums about what changes you’d like and we may get to them. Power toys are not as thoroughly tested as the product. They are not localized or as thoroughly documented, etc. Another characteristic of PowerToys is that we plan to release them “off cycle” by posting updates to the web periodically. Some functionality in the power toys will eventually make its way into the official product and be removed from the power toys. Since this is a fairly new idea for us, I’m interested in feedback on this. As of this writing, none of the power toys have been posted to the web yet but they will start becoming available in the next week or two. In Beta 3, newly available power toys include: tfpt.exe – This is a command-line tool with various functions we wanted to include in the product but didn’t quite make it. It has commands to rollback an entire change set, unshelve and merge the changes with changes you have on your local machine, find changes you’ve made while you are off line and checkout the associated files when you get back online, etc. It’s got some nice functionality in it. VS6 MSSCCI provider – We’ve built a plugin that allows the Team Foundation Server version control functionality to be accessed from VS6 the same way SourceSafe can be. We are working on getting this to work with VS 2003 as well but we have not plans to make it work with VS 2002. TFSServerManager.exe – This one might be a bit longer to come out but it is a tool to help manage a Team Foundation Server. It allows you to view current activity on a server and kill requests if they are “run-away”. It has a monitoring service that will ping the server and record/display server availability data and event log entries. It collects statistics from the server and allows you to see how many files, work items, work item versions, workspaces, labels, … you have and also what operations and users are taking most of the server time. Lastly hit has some facilities for identifying stale data – old shelvesets and workspaces that aren’t being used any longer, for example.

Wow, that’s a lot of writing (sorry to make you read it all) and I haven’t even covered half of it I suspect. I hope, none-the-less, that it is enough to wet your appetite to try it out and see for yourself.