Eric Lee
Dr. Dobb's Journal February 2007
Visual Studio 2005 Team System is a suite of lifecycle tools that expands Visual Studio to enable greater communication and collaboration among distributed software development teams. Scott Swigart recently had the opportunity to sit down with Eric Lee, who at the time of the interview was Product Manger for Microsoft's Visual Studio Team System, and talk about VSTS and what it means to collaborative software development.
Scott: Eric, I want to talk about global collaborative software development, and I know that Microsoft has a product in this space—Visual Studio Team System. Just to set the foundation, give me the 30,000 foot view of Visual Studio Team System.
Eric: Visual Studio Team System is really our evolution from Visual Studio as a developer tool, to Visual Studio Team System as a development tool. This takes individual productivity, which we've always been known for, and extends that to the rest of the team. Visual Studio Team System helps developers work well together and work well with other disciplines that are part of software development. This lets testers, architects, business analysts, and business architects all work well together. And this does it in a way that builds on top of Visual Studio.
Scott: Okay, let's dive down to 10,000 feet then. What are some of the specific features that Visual Studio Team System brings to the table?
Eric: Broadly speaking, you can think of it as four categories of features. We have features that are dedicated towards architects. The center of gravity around that is being able to model solutions, design solution, validate that solution against your datacenter, and be able to make important design decisions early on. Maybe there's going to be a web service that needs pure internet access, and you want to validate that against your existing data center to make sure the middle tier machines that you're going to deploy to have the proper ports open, have the proper service packs, and soon. If there's a disconnect, it's important to solve that at the data center, or in the design, early on and avoid expensive architectural changes later.
There are also new features for testing in Visual Studio. Testing has always been a peripheral task for Visual Studio. You either did it in an ad-hoc fashion, or used third-party tools. With Visual Studio Team System we really wanted to create some first-class functionality for testing. An example is unit testing, where right inside your code editor you can right-click and say you want to create a unit test, and Visual Studio Team System generates the unit-testing code structure for you. As part of that test functionality, we have a testing infrastructure that lets you manage your tests, run those tests locally, or run those tests against a remote machine with an agent and bring those results. We support unit testing, manual testing, web testing, and scalability or load testing, so we have first-class support for testers inside of Visual Studio Team System.
The next set of features is for the enterprise developer. So building on top of Visual Studio, we've integrated a number of engineering tools that are inspired by tools that we've used internally for a long time. One of them is our code profiler. Internally at Microsoft we've had profiling technology that we've used to profile and optimize Windows Server, SQL Server, and all the major products at Microsoft. For the longest time, that profiling technology was a proprietary secret, if you will. Visual Studio Team System is our first chance to productize that technology and make it available to our customers. Now our customers have the same profiling tools that our Windows engineers and systems engineers have. In the same vein are our code analysis tools. We spend a lot of time at Microsoft in code reviews, trying to make sure that the source code that developers write meets a certain design or naming guidelines, and to make sure that common mistakes like buffer overflows are being avoided. What we've done in Visual Studio Team System is take those best practices and implement them in the toolset. We've identified the basic patterns that might lead to a buffer overflow or SQL injection attack, so we've built a grammar checker, if you will, which will analyze the source code and look for those patterns. It's integrated with the build, so every time you build you take advantage of decades worth of software development best practices.
Scott: That's FXCop?
Eric: It's FXCop with some enhanced rules on the .NET side, and PREFast for the C++.
To bring all three of these feature areas together on the server side is the fourth product, which is Team Foundation Server. This is a server-side product, which is new with Visual Studio 2005 Team System, integrates source control, work item tracking, project management, reporting, and build management. When we looked at the market, and looked at what we do internally, we saw that most people, including ourselves, had an independent source control system, an independent version control system, an independent release management system. What that leads to, typically, is a lot of time and effort writing code to stitch those things together. What we wanted to do with Team Foundation Server was provide a unified platform for all that data. It's a place to store your test results, source code files, release configuration, and project management. We use SQL Server 2005 to store that information, but they all get stored into operational databases, and on a scheduled basis, about once every hour, we pull from our operational stores into our data warehouse. That lets you do offline reporting. This is the same type of data warehousing that you might do in the retail industry or the financial industry. We create the warehouse and cube for you. We ship about 20 reports inside the box that build off of that cube, and it's fully extensible, and we have examples for how to apply data mining, how to apply key performance indicators, to that data warehouse.
Scott: Prior to Visual Studio Team System, if you wanted to do distributed development, what did that look like? Compare that to doing distributed development now with Visual Studio Team System and especially with Team Foundation Server.
Eric: The biggest aspect of facilitating global software development is really Team Foundation Server. That's the base for teams to collaborate. If I can take you through a scenario, before Team Foundation Server, when a tester found a bug, how did they share that with the developer? If the developer was down the hall, they've got to maybe zip up a file, send an e-mail, or maybe upload something to your bug-tracking system. That problem expands if the developer happens to sit in another country because it's so much easier to miss an e-mail or an attachment when there are different time zones to consider and people aren't working face to face. With Team Foundation Server, we literally allow you to right-click on your test results that shows the bug, save that to a work item, and that saves the test case and the test results for the developer to work off of. The developer can then run that same test case to replicate the bug.
If you look at Visual Studio 10 years past, and you tried to set up a distributed infrastructure, a lot of the problems were really just trying to get across firewalls and across networks. Visual SourceSafe was our version-control system prior to Team Foundation Server. While it was a pretty good source-control system for an independent developer, it really started to struggle when you tried to bring it across the network, through a firewall, and support 10, 20, 100, or 1000 developers across a development team. It just really didn't have that capability built into it. Team Foundation Server was designed from the beginning to make administration easy, in terms of the protocols and technologies that it uses, and it has that capability built in to support literally thousands of users accessing data concurrently. Visual SourceSafe, and many of the other solutions in the market, use proprietary protocols. Team Foundation Server uses regular XML web services, and just normal HTTP or HTTPS. SQL Server stores that data on the back-end. Internet Information Services (IIS) sits on the application tier. It's using common technologies that, in an enterprise, you're probably maintaining already. From an administration and setup point of view, it's just another web service on your web server, just another couple databases to maintain.
Scott: When I look at Visual Studio Team System, it seems that it's competing against two very different markets. One is the very expensive, proprietary, software development lifecycle tools that were in the market before Visual Studio Team System. The other competitor is the pile of free stuff—all the "N" products, like NUnit, NAnt, and the like. If someone is out there using all of the N's today, and they're using CVS or Subversion, what's it like for them to migrate into Visual Studio Team System?
Eric: Migration isn't too bad. There's one really easy way to migrate, and we did a lot of this in Microsoft, and we've seen a lot of our customers do this. If you can afford to not have your history, the easiest way is to just "get latest" out of your existing system, and check it in to Visual Studio Team System. If you find that you ever need go back, or get some data, keep your CVS or SubVersion system around so you can go back to it if you need to. That's the easiest way to migrate your source.
If you want to keep history, we actually have some partners in this space that do some migration solutions. Our partner, ComponentOne, makes a CVS and Subversion migration solution. They do migration and mirroring. So you can do a full migration, or you can trickle migration. As you make a change and check it in through CVS, it gets replicated to Team Foundation Server. When you make a change in Team Foundation Server, it gets replicated to CVS.
Scott: Interesting. I didn't know about that.
Eric: Yeah, so as you get more comfortable, and get more people up on Team Foundation Server, you can wean yourself off of CVS if you want to. That's something that's been pretty popular with our customers.
Scott: One of the things that you're alluding to a lot is the use of Visual Studio Team System inside of Microsoft. You're almost putting Microsoft forward as a case study for this because you've had to migrate from other source-control systems. Talk a little about how Team Foundation Server is being used inside of Microsoft, and specifically, because Microsoft is a global software company, with things like the India Development Center, Microsoft is doing software development all over the world. Talk about how that works inside of Microsoft.
Eric: Sure. Just to give you an insight into what we call our "dog fooding" process, we try to get internal teams to use Team Foundation Server to flush out customer issues, bugs, and the like. The development team that built Team Foundation Server sits in four locations worldwide; Redmond, North Carolina, Copenhagen, and India. All of those development centers use a centralized server inside of Redmond. This is where we've been able to realize some of the benefits of building on top of existing technology. Over the years SQL Server, IIS, and the like have all been pretty efficient, and have optimized themselves. What we've found is that in supporting the four development centers that make up the Visual Studio Team System team, with about 800 users overall, all we need in terms of hardware is a dual-proc web server, and a quad proc database, which is pretty modest hardware to support that entire distributed team.
One technology that came out of this experience was our Team Foundation Server cache process. All the communication in Team Foundation Server is web service traffic, not unlike web browser traffic in general. One of the things that HTTP traffic lends itself to is caching. Our India development center came on late, and they started very small, with just a couple of developers, and then they expanded really fast. They were literally adding two or three developers per week. One of the most expensive operations in a team environment is that first sync operation, where you're pulling current the state of the project onto your workstation. Because you initially need everything, it's a lot of traffic. We build our caching process to facilitate spinning up a development team in a remote location. For the first developer, the sync was a little slow for them, but once they pulled that data down, it went into our cache process. Subsequent developers who joined the India Development Center (IDC) didn't have to pull everything across the wire from Redmond to Hyderabad. They just pulled 90 percent from the local cache, and the 10 percent that were out of date on the local cache. That's an example of one of the innovations that came out of the dog-fooding process.
Scott: You're able to set up a server at the remote location that just does caching?
Eric: Yep. It's a real savings for distributed teams. We have a 3-MB pipe between India and Redmond, and we didn't do any network upgrade between those locations. We thought this would be typical for many of our customers. We tried to minimize network traffic that goes back and forth, and one of most obvious ways was with caching.
Scott: Visual Studio Team System is a version 1 product, and my impression is that it's getting pretty good traction. What do you see as some of the future opportunities? Obviously the scenario of global or distributed software development is important. Being able to work disconnected and in sync. Where is Microsoft going to be focusing?
Eric: There's a great deal of interest in this thing known as IT governance. It's important to be able to know what people are doing, and be able to enforce certain policies at certain times. While that's not problem specific to distributed development, it tends to be exacerbated by distributed development. You might not have as much visibility into a remote team. Being able to enforce those things in a Visual Studio way is important.
Offline support is important. Optimizing traffic between distributed sites is important. Being able to provide alternate user interfaces is important. For example, right now you have Visual Studio on the developer side. You have Project or Excel on the project management side. We're looking at maybe doing a Web only front end, which is something that our partners have been very successful with. We may or may not get into that, but we're interested in things along those lines. We want to be able to dial the client experience. If you're working offline, you might want to look at your offline work items. If you're in a very limited bandwidth scenario, you might want to use the Web-only front end.
Scott: Are you envisioning Orcas [Editor's Note: Orcas is the code name for the next version of Visual Studio.] as being a big release for Visual Studio Team System? I'm assuming that you're shipping in line with the Visual Studio release cycle, and not releasing features off-cycle, is that correct?
Eric: The Orcas plans are still underway. We will ship in sync with Visual Studio, but it's up in the air right now as to whether Orcas will be a major release for Visual Studio Team System, or more of a point release. It looks like the latter right now, but those plans are still being put together.
Scott: Okay, to sum up what we've covered at this point; Visual Studio Team System is Microsoft's tool for enabling global development. It's being used within Microsoft. Are there any case studies external to Microsoft that you can point to?
Eric: Yeah, we have case studies that I can point you to. In terms of Visual Studio Team System development, we've been very cognoscente to not build a tool that only serves the needs of the Visual Studio Team System development team. While our Visual Studio Team System development is quite large, 800 people, the way that Visual Studio Team System teams works may be a bit different than our customers. Our release cycles are a little longer, for example. We wanted to have some teams in Microsoft that are smaller, more agile, maybe that have to follow CMMI compliance. We've had them adopt Visual Studio Team System as well. These are teams like our financial tools, sales tools, and some internal business process software teams have adopted Visual Studio Team System. That's where we have a number of case studies coming from. We wanted big ISV-style development teams, as well as smaller line of business, more agile, teams.
Scott: If someone is interested in kicking the tires on Visual Studio Team System, what are the options for evaluating it?
Eric: There is a trial DVD that can be ordered that's good for 180 days. That includes the client pieces, the architect, developer, and test pieces, as well as Team Foundation Server. We also have some hosted virtual labs, which is a zero-install way of evaluating Visual Studio Team System. When you do the virtual lab, you're provided with a script to help you work with various aspects of Visual Studio Team System. We have higher level case studies, which give some experiences that our customers have had. And there's a really growing set of community resources such as blogs and forums.
Scott: You've also mentioned that your partners are doing a number of interesting things. A lot of times, the partners take on the role of addressing pain points in the current product. What are some of the kinds of things that you're seeing partners develop? What are some things that you've seen where you've thought, "Wow, that's cool."
Eric: Migration is certainly one of them. The pure web interface is another. They've done a great job. In fact, they've done such a good job that they've influenced our product plans. There's another partner that has taken Team Foundation Server and brought it across platforms. We have a complete web service interface for Team Foundation Server, and they've built a Java client interface to communicate with Team Foundation Server through those web services. We're seeing clients running on Linux or Mac OS, using Eclipse, and interfacing with Team Foundation Server. Those are some of the examples that we're seeing for partner products.
We're also starting to see a lot of partner services. We're seeing solution-providing companies also provide training, mentoring, deployment, or administrative services for Visual Studio Team System.
Scott: Obviously Visual Studio Team System is focused at the Microsoft developers, and so it's likely that those shops already have Windows boxes in-house, which is what you need for Visual Studio Team System and Team Foundation Server. But I think it is interesting that you mention that you have people who aren't using Visual Studio still using Team Foundation Server.
Eric: Yeah, we have two partner companies that are building those sorts of interfaces, and it's been really interesting to see. When we're designing Team Foundation Server, we always thought, "Well, it might be possible to do this," and it's very interesting to watch companies go out and be successful with this.
Scott: How far up have you seen a given Team Foundation Server scale? You built it with certain requirements in mind, but what's the highest that you've seen?
Eric: You know, we were just talking with this customer, and we'll probably do a case study on them. There's this customer in Brazil that has 5000 users on a single Team Foundation Server, which is actually higher than we thought. In our requirements, we spec'd 3500 users per Team Foundation Server installation, but we've seen this customer go much higher than that. It really varies depending on what work each user is doing, but you should be able to reach at least 3500 per install.
Scott: Is that an area that you're looking at for future work?
Eric: You mean to go higher than 3500?
Scott: Or be able to have a single developer simultaneously connected to multiple Team Foundation Servers.
Eric: I think it's going to be the latter. As far as supporting larger development teams, we will do work in that area, to support some of the really big teams that we've seen like the Windows team or the Office team, the teams that literally have 10,000 developers. But our most valuable work will be to federate Team Foundation Server more easily than you can today, to have four or five Team Foundation Servers that people can collaborate through, and be able to move projects between those Team Foundation Servers. A lot of work will be done in that area, probably not for that Orcas time frames, because the work is significant, but probably the release after that. When you look at scaling up and scaling out, most of the work will be done in scaling out.
Scott: Anything else cool on the horizon?
Eric: In terms of our roadmap going forward with Visual Studio Team System, you've probably heard the term Application Platform. One of the things that we've seen the early adopter, or edge customers, be successful with is building solutions that integrate Visual Studio Team System, BizTalk Server, and SQL Server. We're trying to bring that to more of our mainstream customers, and we're calling that the Application Platform. Going forward, you're going to see us doing more where we say, "Hey, Team Foundation Server stores its data in a SQL Server database, maybe there's some data mining that we can do. Maybe there are some key performance indicators that we can use to report on teams across the world in a centralized fashion." Maybe we can use BizTalk Server 2006 to integrate some of our orchestrated business processes with software development processes. That's an area that we're pretty interested.
Scott: Thanks for taking the time to chat.
Eric: Thank you.
Editors Note: Since this interview took place, Microsoft has continued to expand its lifecycle offering by releasing a new member of the Team System family, Visual Studio Team Edition for Database Professionals, focused on managing change to databases throughout the lifecycle and helping integrate the database developer and database administrator into the overall application lifecycle.
Case studies focused on Microsoft using its own technologies: www.microsoft.com/ technet/itsolutions/msit/vs.mspx
Customer case studies: members.microsoft.com/CustomerEvidence/Search/AdvancedSearchResults.aspx?Flag= 0&AndTaxID=18782
Visual Studio Team System partners: msdn.microsoft.com/vstudio/teamsystem/downloads/partners/default.aspx.