Another Milestone in TFS Internal Adoption
On July 21st, we hit another important milestone in adoption of TFS within Developer Division. If you’ve followed my blog over the years, you know that our own use of TFS is an important part of our process of ensuring the product is a great product. We first started using it in 2004 and have gradually been increasing the scope and magnitude. For the last couple of years, most of the division has been using most of the features of TFS 2008. In the spring we upgraded to TFS 2010 but we didn’t really expand the set of features being used. The one feature that’s been in the product quite a while but has had limited adoption inside Developer Division is the TFS Build capability. Since we shipped VS 2010, we’ve been in a period of our product cycle that we refer to as “MQ”. It stands for “Quality Milestone”. MQ is a period between product cycles where we focus on our engineering processes and tools. We learn from the challenges of the previous product cycle and prepare to do the next product cycle even better. At the same time we are planning what the feature set of the next product cycle will be. One of our many goals for the MQ period was to adopt TFS build as a key part of our development process. On July 21st we had our first successful end-to-end build of all of VS in the central build lab driven using TFS Build! This is a VERY cool accomplishment. It’s hard for me to explain sophistication and degree of automation in the central VS build lab where they do over 80 full builds of VS a day on different branches, for different CPUs and different flavors (retail, debug, …). Many of the builds also get test results. Replacing the previous automated build process, which was a complex bundle of custom exes, scripts, etc with a TFS workflow based build was a significant undertaking. We’ve still go work left to do to polish it but it’s great to see that we are now seeing successful end-to-end builds. In addition to targeting the main build lab processes, in MQ, we also targeted replacing our gated checkin systems (we have a couple of internal ones we’ve used for years – Gauntlet and Snap are two I know of). In Dev 11, many teams will be using TFS 2010’s new gated checkin capabilities instead. When we embarked upon using TFS’s gated checkin system for DevDiv, we realized that there were some gaps in the 2010 feature set and what the division was going to need. The single most significant one had to do with scale. The VS build is fairly expensive and we run quite a lot of tests as part of our gated checkin process. Given the size of the teams, there simply aren’t enough hours in the day to run every individual checkin through the full validation process serially. We needed a way to “batch” checkins so that we could validate several of them at once. At the same time, we don’t want one “bad” checkin to cause other “good” ones to fail. We also didn’t want to require manual intervention every time there is a bad checkin. So, as part of MQ, we’ve enhanced the TFS gated checkin features to be able to batch and validate multiple checkins at once. If the validation fails the system will automatically “back off” and validate the checkins one at a time until it finds the one that caused the failure – rejecting that one and accepting the rest. These new capabilities will be rolled into the next version of TFS. Beyond that, most of the work involved integrating TFS Gated Checkin into our various internal systems and processes using standard extensibility mechanisms. The next big push for internal adoption of TFS features will be test and lab management. We already use the new 2010 test and lab features in some product groups but we haven’t done a division wide push for central adoption yet. I expect that will happen between our Dev 11 and Dev 12 product cycles.
Brian
Light
Dark
0 comments