Using Visual Studio 2008 to Improve Software Development
Deploying Visual Studio Team System 2008 Team Foundation Server at Microsoft
Technical White Paper
Published: June 2008
The following content may no longer reflect Microsoft’s current position or infrastructure. This content should be viewed as reference documentation only, to inform IT business decisions within your own company or organization.
Technical White Paper, 926 KB, Microsoft Word file
Products & Technologies
Microsoft IT wanted to improve and enhance developer productivity. The former development environment at Microsoft IT was made up of different technologies which made cross-project reporting difficult. Additionally, program managers experienced difficulty with managing projects from a business perspective.
The deployment team upgraded the Team Foundation Server infrastructure to Visual Studio 2008. Additionally, new features in Visual Studio 2008 gave users Web-based access to Team Foundation Server.
To support the IT infrastructure in the largest software company in the world, the Microsoft Information Technology (Microsoft IT) department is responsible for the ongoing development of more than 1,400 software applications that consist of approximately 2 million lines of code. These applications are a critical part of managing the day-to-day business operations at Microsoft. These business operations include the following:
- Software licensing and operations
- Other corporate functions such as human resources (HR), legal, and finance.
Microsoft IT employs approximately 11,000 people who develop and support internal business applications.
As part of its mandate to support internal business applications, Microsoft IT implemented the Program Delivery Engineering Excellence strategic initiative. The goal of this initiative is to improve code quality, developer productivity, and the accuracy of the programming schedule and the programming budget for software development at Microsoft IT.
To make these improvements, Microsoft IT created a series of metrics that it can use to define guidelines for software development among all of its development groups. Additionally, Microsoft IT gave these groups the tools to gather the appropriate metrics.
As part of the movement toward supporting formalized development methodologies, Microsoft IT deployed Microsoft® Visual Studio® 2005 Team Foundation Server in its environment. This deployment was very successful, and many projects were migrated to the new system. With the development of Microsoft Visual Studio 2008, Microsoft IT determined that it could expand on the improvements that Visual Studio 2005 made to developer productivity without increasing hardware costs. Additionally, because of improvements in the functionality and feature set of the new product, Microsoft IT determined that it could reduce costs when migrating development projects to the new system and increase overall developer productivity with the new system.
This document describes how Microsoft IT implemented Microsoft Visual Studio Team System 2008 Team Foundation Server to improve software development at Microsoft IT.
An IT Showcase webcast called How Microsoft IT Leverages Microsoft's Enterprise IT Development Platform includes a discussion on this topic. The webcast is available at http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032379180.
Note: For security reasons, the sample names of internal resources and organizations used in this document do not represent actual names used within Microsoft and are for illustration purposes only. In addition, the contents of this document describe how Microsoft IT runs its enterprise data center. The procedures and processes included in this document are not intended to be prescriptive guidance on how to run a generic data center and may not be supported by Microsoft Customer Service and Support.
When considering Microsoft products and technologies, corporate decision makers often request information about experiences with using these products and technologies within Microsoft. Microsoft IT not only provides IT services for Microsoft but also acts as the first customer for each new release of server and business productivity software. Because Microsoft IT requirements are among the most technically challenging in the world, the methods that Microsoft IT uses to deploy these technologies and the experience that Microsoft IT gains from these deployments often provide meaningful deployment and operational guidelines for other organizations that want to deploy Microsoft products. Additionally, because Microsoft IT works with these Microsoft products from the prerelease editions to the Release to Manufacturing (RTM) editions, Microsoft IT provides valuable feedback about features and functionalities. This feedback not only improves the software products throughout their development, but also helps Microsoft customers and partners successfully deploy these products and technologies.
Overview of Software Development at Microsoft IT
Program managers at Microsoft IT face similar challenges to the challenges that program managers face at any other large software development organization. These challenges are to accurately manage the delivery and costs that are associated with a software development project, to monitor the progress of the project, and then to review the finished project to evaluate its overall success.
Microsoft IT has approximately 2,000 developers worldwide. These developers are mainly located in the following areas:
- Major Microsoft IT development centers in Redmond, Washington, United States, and in Hyderabad, India
- Smaller development centers throughout Europe and Asia
Along with software developers, project teams can consist of project managers, business analysts, application architects, and software testers.
In the past, the project teams found that managing and coordinating the overall project delivery effort was difficult and time-consuming. Because the tools were not well integrated with each other, managing program requirements or tracking work-item progress was difficult. Therefore, during program development, program managers frequently experienced problems in the following areas:
- Traceability. Program managers established program requirements by using
static documents. These documents were difficult to keep updated, and they generally
became outdated very early in the project development process. Because no effective
method was available to link work items to a particular program requirement, program
managers had difficulty making sure that a project's intended scope did not change
throughout the development process. Therefore, the following problems were more
likely to occur during the project development process:
- Scope creep. Program changes were made or program features added without passing the modifications through the appropriate approval stages.
- Missed features. Program features or program functionality would be missed during the project's development. Although the missed feature or functionality would be discovered during the User Acceptance Testing (UAT) phase of the project development cycle, it could cost up to five times as much to add the missed feature or function at such a late stage in the development process than it would during the typical development period.
- A lack of standardized metrics. No standardized platform was available from which to track programming tasks. Therefore, no effective method was available to assign a dollar figure or business value to a particular program feature. Program managers therefore had difficulty determining the return on investment (ROI) for a feature or establishing a business case for the development of a feature.
- A lack of visibility. Program managers could not easily determine the progress of the particular parts of a project. There was no easy way to summarize distinct parts of a programming project according to work items or progress. Therefore, program managers could not easily manage or report on the overall progression of a project.
Additionally, although project teams used similar methodologies and tools, project development at Microsoft IT used a silo approach–a system of decentralized non-standard processes for program development among business groups.
Figure 1 illustrates the program development approach that business groups formerly used in Microsoft IT.
Figure 1. Earlier program development approach
In this environment, smaller development teams used commercially available products, such as Microsoft Visual SourceSafe®, for source control and version tracking. Larger teams used a set of internally developed tools for work-item tracking, source control, version tracking, and bug tracking. These tools all operated separately and were located on separate servers. Additionally, because the IT groups planned the infrastructure for each project's tools separately, project integration was very difficult.
Team Foundation Server
The development teams at Microsoft IT needed a business solution to manage multiple program development projects. The development teams required standardized methods to perform the following tasks:
- Generate program requirements and assign value statements to those requirements. The teams needed to assign business benefits, ROI, and cost values to individual program requirements.
- Break down program requirements into individual work items, and then generate tasks that are based on each work item.
- Use a tool to parse discrete pieces of a project and then, based on the individual program pieces, track the progress and overall success of the project.
To help meet these requirements, program development at Microsoft IT started to adopt formalized development methodologies and frameworks. These include the following development methodologies:
- Team Software Process/Personal Software Process (TSP/PSP)
As a key part of implementing these development methodologies, Microsoft IT deployed Visual Studio Team System 2005 in April 2006. Program development teams began to migrate projects to Visual Studio 2005 Team Foundation Server to take advantage of the new features and functionality of the system. As a starting point for the standardization of programming practices, Microsoft IT required only that the teams used Team Foundation Server to manage the following:
- Source code control
- Defect management
However, program development teams also began to use Team Foundation Server for operations such as work-item tracking and reporting. Figure 2 illustrates the Team Foundation Server architecture.
Figure 2. Team Foundation Server architecture
By using Team Foundation Server for source code control and defect management, Microsoft IT calculated that it could achieve approximately a 10 percent increase in developer productivity.
Visual Studio 2008
The deployment of Visual Studio 2005 Team Foundation Server was very successful, and program development teams continued to migrate projects to the new system. However, Microsoft IT determined that it could gain even greater benefits from the new functionality and features that are available in Visual Studio 2008. Additionally, because of performance improvements and code enhancements in Visual Studio 2008, Microsoft IT determined that it could deploy Visual Studio Team System 2008 Team Foundation Server without modifying the hardware infrastructure that was already in place.
The promise of an unchanged infrastructure gave Microsoft IT the cost-savings argument that it required to deploy Visual Studio Team System 2008 Team Foundation Server in its environment. For example, Microsoft IT did not have to budget or justify hardware expenditures to take advantage of the new features that are available in Visual Studio 2008. Instead, Microsoft IT determined that it could perform an in-place upgrade of its Visual Studio 2005 Team Foundation Server deployment to Visual Studio 2008.
To this end, starting with Visual Studio 2008 Beta 2, Microsoft IT deployed Visual Studio Team System 2008 Team Foundation Server throughout its Team Foundation Server implementation. Next, Microsoft IT upgraded Visual Studio 2008 Beta 2 to the release version of Visual Studio 2008. The current Team Foundation Server deployment in Microsoft IT consists of three physical Team Foundation Server instances and one virtual Team Foundation Server instance.
Note: Although Microsoft IT currently has four Team Foundation Server instances, more than 30 Team Foundation Server instances have been deployed in other departments throughout Microsoft.
Figure 3 illustrates the architecture of the physical Team Foundation Server instances in Microsoft IT.
Figure 3. Physical Team Foundation Server instance
Figure 4 illustrates the architecture of the virtual Team Foundation Server instance in Microsoft IT.
Figure 4. Virtual Team Foundation Server instance
Physical Server Characteristics
All the physical Team Foundation Server instances have similar hardware characteristics. The following list shows the hardware characteristics from one of the physical Team Foundation Server instances:
- Application tier. Computers that have four processors and 4 gigabytes (GB) of random access memory (RAM) and that are running the Windows Server® 2003 operating system.
- Data tier. Computers that have four dual-core processors and 32 GB of RAM and that are running Windows Server 2003 x64 Edition.
- Analysis servers. Computers that have four dual-core processors and 32 GB of RAM and that are running Windows Server 2003 x64 Edition.
Note: Microsoft IT did not require specialized hardware in its Team Foundation Server deployment. Instead, because of the capabilities of Visual Studio 2008, Microsoft SQL Server® 2005, and Windows Server 2003, Microsoft IT was able to deploy Team Foundation Server by using computer systems that are considered to be commodity hardware. The use of commodity hardware enables Microsoft IT to experience a considerable cost savings in its Team Foundation Server environment.
Virtual Server Characteristics
Together with the three physical Team Foundation Server instances, Microsoft IT deployed Team Foundation Server in a virtual environment. This deployment is configured as a dual-server environment that is installed on Microsoft Virtual Server 2005-based virtual machines.
Microsoft IT deployed Team Foundation Server in a virtual environment to meet the requirements of a particular team. The team had specific security requirements but was not large enough to require the capacity of a stand-alone deployment. Microsoft IT also determined that by using a virtual environment, it would experience a considerable cost savings with regard to the initial deployment and ongoing data-center costs.
Note: Hosting services on physical servers in Microsoft IT costs approximately 10 times as much money as hosting the same services in a virtual environment.
Product groups host all new development projects in Microsoft IT on the Team Foundation Server implementation. Additionally, product groups continually migrate projects from the earlier systems to Team Foundation Server. The following table illustrates the number of projects that product groups currently host on the Team Foundation Server instances.
Table 1. Team Foundation Server Hosting Statistics*
Source code files
Physical instance 1
Physical instance 2
Physical instance 3
* Statistics gathered in March 2008
The architecture of a Team Foundation Server implementation contains the following three tiers:
In Microsoft IT, the Team Foundation Server back end consists of the application tier and the data tier. The Microsoft IT operations team manages these tiers. The individual product groups that host their projects in the Team Foundation Server back end are considered clients of the hosting service. Individual product groups manage their own client tier deployments. Because of this separation of responsibility in the Team Foundation Server infrastructure, Microsoft IT handled the Visual Studio 2008 deployment in two distinct stages. The operations team first deployed Visual Studio Team System 2008 Team Foundation Server in the application tier and data tier. Then, individual product groups deployed Visual Studio 2008 in the client tier.
Application Tier and Data Tier
The operations team was satisfied with the performance and manageability of Visual Studio 2005 Team Foundation Server. However, the team looked forward to the deployment of Visual Studio Team System 2008 Team Foundation Server to help resolve the following two issues that the team experienced in its Visual Studio 2005 Team Foundation Server deployment:
- Server installation was complicated.
- The team was unable to reclaim space from back-end databases.
In the multiple-server Team Foundation Server topology that Microsoft IT uses, the operations team found server installation to be overly complicated. The team had to perform a separate Visual Studio 2005 Team Foundation Server installation on each server in a dual-server deployment. This issue, together with the numerous steps that are required to install Visual Studio 2005 Team Foundation Server, led to a greater likelihood that team members would experience installation problems. For example, in an upgrade scenario, the team had to first remove Team Foundation Server from each server, and then reinstall the product on each server. The team found this procedure to be problematic and time-consuming.
During the initial deployment of Visual Studio Team System 2008 Team Foundation Server, and during subsequent upgrades to the release version of the product, the operations team experienced a much easier and simplified installation procedure. The team no longer had to perform multiple Team Foundation Server installations. Instead, the team only had to install Team Foundation Server on a server in the application tier. Team Foundation Server would then connect to SQL Server in the data tier and complete the installation.
The operations team recorded far fewer installation issues with Visual Studio Team System 2008 Team Foundation Server than it did with the earlier version of Team Foundation Server.
Reclamation of Space in the Data Tier
Team Foundation Server projects are hosted on high-speed storage in the data tier. To keep storage costs to a minimum, Microsoft IT needed the ability to remove unnecessary projects from the data tier.
Over time, outdated or otherwise unneeded projects accumulated in Team Foundation Server. However, because the operations team was unable to delete the data from the back-end database, the groups that owned the projects continued to pay the storage costs to host the projects.
The operations team experienced one issue in which data from a pre-release version of Visual Studio 2005 was copied to another server as part of a process to move users from one server to another server. In this scenario, the project teams did not delete the projects from the original server correctly. Therefore, the project data remained in the Team Foundation Server back end. These unneeded projects accounted for approximately 300 GB of unneeded data in the Team Foundation Server instance.
Visual Studio 2008 supports deleting data from the Team Foundation Server back end. After Microsoft IT completed the deployment of Visual Studio Team System 2008 Team Foundation Server, the operations team started the process of reclaiming the space that the 300 GB of unneeded data was using.
For the Microsoft IT teams that support the Team Foundation Server client tier, a critical consideration during the deployment of Visual Studio 2008 was end-user downtime. Downtime in the client tier could have affected developers, testers, and project managers. For one group, downtime during the upgrade to Visual Studio 2008 could have directly affected more than 800 people.
The deployment teams in the client tier coordinated their upgrade operations with the Microsoft IT operations team. However, because Visual Studio Team System 2008 Team Foundation Server supports Visual Studio 2005 clients, teams did not have to upgrade the client tier immediately. This benefit enabled the teams to carefully plan each client upgrade to Visual Studio 2008 to minimize or eliminate unscheduled downtime. Therefore, the teams upgraded product groups to Visual Studio 2008 on a team-by-team basis, taking advantage of release cycles when users had finished releasing one version of a product but had not yet started the next version.
To deploy Visual Studio 2008 in the client tier, the teams took the following approach:
- Upgrade existing projects
- Upgrade the build servers
- Upgrade build scripts
- Install the Visual Studio 2008 client program on end-user computers
Build Server Upgrades
Although the operations team manages the servers in the application tier and data tier, the clients of the Team Foundation Server implementation manage the build servers. To use the build servers with the upgraded Team Foundation Server deployments, the teams in the client tier had to upgrade the build servers to Visual Studio 2008. The teams found the upgrade of the build component to Visual Studio 2008 to be an easy and quick operation. However, because of increased functionality in Visual Studio 2008, and because of changes in the build component in Visual Studio 2008, the teams also had to update the Team Build definition scripts. The Team Build definition scripts contain the projects to compile, the custom logic, and so on. Therefore, the teams had to examine and update each script to make sure that it would run in a Visual Studio 2008 environment. The teams completed this stage of the upgrade process in approximately one month.
Visual Studio 2008 includes a feature called multi-targeting. This means that developers can use Visual Studio 2008 to create applications that target the Microsoft .NET Framework version 2.0, the Microsoft .NET Framework version 3.0, or the Microsoft .NET Framework version 3.5. To prepare for the installation of Visual Studio 2008, Microsoft IT had to upgrade existing Visual Studio 2005 projects to take advantage of the new features in Visual Studio 2008. Because some product groups had more than 100 solutions and projects spread over various locations, Microsoft IT created a small team that was dedicated to converting the Visual Studio 2005 solution files to Visual Studio 2008. This team used the following process to convert projects to Visual Studio 2008:
- The conversion team coordinated with a development team to convert each of the particular development team's projects to Visual Studio 2008.
- After all the development team's projects had been upgraded, the development team upgraded all its client computers to Visual Studio 2008.
- The conversion team moved on to the next development team.
This team-by-team progression provided Microsoft IT with an incremental client upgrade throughout the development environment. Additionally, the focus on upgrading between project release cycles minimized developer downtime.
Although Visual Studio 2008 is multi-targeted, it does not compile Microsoft .NET Framework version 1.1 code. The process to migrate .NET Framework 1.1 code to Visual Studio 2008 is not as simple as the process to migrate the Visual Studio 2005 projects to Visual Studio 2008. Therefore, Microsoft IT determined that it had to maintain a Microsoft Visual Studio 2003 implementation to support the large .NET Framework code base that it manages.
Note: The upgrade of a .NET Framework 1.1 project to Visual Studio 2008 requires both the project files and the code to be upgraded.
User Experience Enhancements
The deployment and subsequent upgrades of Visual Studio Team System 2008 Team Foundation Server focused on improved performance and data management in the back end together with the easy migration of projects and the reduction of costly downtime in the client tier. However, the overarching goal of the deployment of Visual Studio Team System 2008 Team Foundation Server was not to improve the underlying infrastructure. Instead, Microsoft IT deployed the product to meet the following goals:
- Improved developer productivity
- Enhanced managerial visibility into the overall project development process
Additionally, although developers had requested Visual Studio 2008 to take advantage of features such as the .NET Framework 3.5, the main benefits that Microsoft IT experienced arose from end-user enhancements and improvements in Visual Studio 2008 in the client tier. These enhancements and improvements include:
- Improved visibility in project details
- Enhanced Team Build functionality
- Integrated power tools
- Team System Web Access
- Improved source control management
Formerly, program managers in Microsoft IT experienced a lack of visibility into the detailed progress of a project. Specifically, program managers wanted a tool to enable them to gain better insight into the details of engineering tasks, such as individual program bugs and the breakdown of programming tasks. Because no mechanism was available to provide visibility into how the various development tasks progressed over time, program managers felt that they could not work as proactively as they wanted with the development process. Because there was no effective method to view the timeline of project tasks, program managers could not easily determine whether any issues threatened a project's expected delivery date.
The deployment of Visual Studio 2008 together with work-item tracking in Team Foundation Server provided program managers with a tool to obtain accurate and up-to-date reporting on the various tasks that composed each project. By creating reports in Visual Studio 2008, program managers gained an important entry point into a project. Managers could view the overall progress of a project or drill down into the individual work items of a task.
Program managers used this increased visibility into projects as an overview of the project's health as well as an entry point for discussion. By examining the progress of individual project pieces, a manager could quickly identify issues that might affect the overall project delivery, and then respond to the issues as appropriate. Visual Studio 2008 enabled program managers in Microsoft IT to become more proactive than before during a project. Figure 5 illustrates some of the Team Foundation Server reporting capabilities that are available in Visual Studio 2008.
Figure 5. Visual Studio 2008 reporting
Enhanced Team Build
After the deployment of Visual Studio 2008, developers expressed increased satisfaction with the enhanced functionality of the Team Build component. The two features that made the greatest improvement with regard to end-user satisfaction with the Team Build component were the following:
- Inclusion of custom code between build operations
In Microsoft IT, developers frequently required the results from one build operation to be available to another build operation. For example, developers had experienced an issue in which a .dll file that is the result of one build operation is required by a second build operation. With the earlier versions of Visual Studio, the developers could not insert any custom code into the build scripts. However, because Visual Studio 2008 enables developers to include custom code between the build operations, developers were able to make the results of one build operation available to another operation. This feature helped streamline the build process.
- Incremental get operations
The first operation that the Team Build process performs is to copy the latest code from the Team Foundation Server source code repository to the build computer. In earlier versions of Visual Studio, developers experienced significant wait times for the code to be copied to the build computers. Because Visual Studio 2008 supports incremental get operations in which only the changed code is copied to the build computer, developers experienced dramatically increased performance during the build process. Build operations ran much faster than they did with earlier versions of Visual Studio.
Integrated Power Tools
Team Foundation Server power tools were available to developers in earlier versions of Visual Studio. However, Microsoft IT found that because the tools were available only from the command line, developers were less likely to use them. With the integration of many power tools in Visual Studio 2008, Microsoft IT found that developers used these tools much more frequently–especially source-control-related power tools. The following two tools experienced significantly increased usage:
- TreeDiff. This command enabled developers to see the differences between two folders in a source control repository.
- Annotate. This command enabled developers to view who changed each line in a file. This feature helped developers communicate with another developer to determine why he or she made a particular change in a file.
Team System Web Access
The Visual Studio Team System Web Access feature enables project teams to access Team Foundation Server by using Web browsers. In Microsoft IT, Team System Web Access generated one of the strongest positive user experience responses. Figure 6 illustrates the Team System Web Access home page.
Figure 6. Team System Web Access home page
Generally, solution and delivery teams in Microsoft IT used Team System Web Access. However, program managers also heavily used this feature. Program managers found that reporting on project progress during meetings was much easier because they could use a Web browser to access Team Foundation Server and then speak about individual report items. Also, program managers could easily update bug information during team meetings to prioritize bugs.
Additionally, because the Team System Web Access information is returned as query string parameters, program managers could more easily request information about certain aspects of a project. For example, instead of having to describe an issue in an e-mail message or over the telephone, a manager simply sent an e-mail message that contained a link to the particular query. This functionality made collaboration much easier during project development. Figure 7 shows the Team System Web Access Work Items page.
Figure 7. Team System Web Access Work Items page
Although the same Team Foundation Server information is available in the Visual Studio client program, program managers were less likely to install Visual Studio 2008 together with the Team Foundation Client program to access the information. Additionally, the ability to send a link to a query in an e-mail message gave program managers additional incentive to use Team System Web Access over the Visual Studio client to gain visibility into the progress of a project.
Program managers, solution teams, and delivery teams found Team System Web Access to be a key part of their collaborative efforts during the project development process.
Improved Source Control Management
In the past, development teams in Microsoft IT experienced quality issues that were directly related to an inability to remove information from source code repositories.
Microsoft IT development managers have the rights to create the branch structure for source control in their projects. Because of the many different teams in Microsoft IT, and because of differences in how the teams are organized, the following issues could occur:
- A manager could unintentionally create an incorrect branch or use a branching strategy that was not optimal for a project.
- A manager could give developers the rights to create their own branches. Then, the developers could create branches that did not follow a prescribed branching strategy.
- Third-party developers could use a non-standard branch structure or might not even create branches.
Because of these issues, an incorrect branch structure might be created for a project. Because managers were unable to remove the incorrect branches, they would have to notify the appropriate teams about which branches to work from. However, situations occurred in which a developer or team worked from an incorrect branch. In one particularly serious case, the source code from a critical share was overwritten by work from an incorrect branch. Although this problem was discovered during the UAT phase of the project, the problem delayed the project and greatly increased costs.
Note: The Development and Test group at Microsoft IT has established a leadership team to develop standards for branch organization in Microsoft IT.
Along with quality issues that were related to branch structure, development teams experienced performance issues with regard to the system for source code control. Over time, approximately 40 unneeded projects accumulated in the source control system. These projects represented approximately 30 megabytes (MB) of additional cache size that had to be loaded to parse the source code repositories. This extra cache size caused performance degradation when developers accessed source code repositories. Additionally, because development managers were unable to delete projects, developers had to parse unneeded folder structures to locate the appropriate projects.
Also, situations occurred in which large cache refresh operations caused significant developer downtime. In one situation in which the cache size was approximately 140 MB, a delete event triggered a cache refresh operation that affected 2,000 users. The refresh operation caused a work stoppage of all the projects on that server for approximately 2.5 days, which severely affected project schedules for the projects that were hosted on the server.
Because of the extensive costs of developer downtime that the cache issues caused and because of the development costs and confusion that branch structure mistakes caused, managers in Microsoft IT looked forward to the project pruning functionality in Visual Studio 2008. After the installation of Visual Studio 2008, development managers quickly corrected mistakes in the branch structure of the source code repository. Instead of having to react to an incorrect branch structure by instructing development teams to avoid certain branches, development managers can now quickly delete or re-create an incorrect branch structure. Also, development managers have been able to permanently delete unneeded projects, freeing cache usage to increase connection speeds with Team Foundation Server.
The Team Foundation Server implementation has provided several benefits and cost savings to Microsoft IT. The following is a list of the key benefits that Microsoft IT experienced:
- A simplified development environment. By using Team Foundation Server, Microsoft IT has taken great strides in standardizing program development in Microsoft IT. Developers from different groups now use similar methods to access and manage code.
- Improved visibility in project progression. Managers can use tools to view detailed information about the progress of projects, from individual work items to rolled-up program pieces. When using Team System Web Access, managers and solution delivery personnel can easily view and collaborate on project development issues from any computer.
- Improved source code management. Teams can now easily manage the branch structure for their projects, helping to reduce or eliminate costly mistakes with regard to management of source code. Teams can now permanently delete projects to reduce cache size and speed access to repositories.
- Enhanced deployment. Server installation in the Team Foundation Server back end is easier and less prone to user error. Because Visual Studio Team System 2008 Team Foundation Server supports Visual Studio 2005 clients, upgrade operations in the client tier are much easier, virtually eliminating unscheduled end-user downtime. Microsoft IT received feedback from end users indicating that apart from upgrading the build definition scripts, the Visual Studio 2008 deployment in the client tier had approximately the same impact on users as would the installation of a service pack.
During the deployment of Visual Studio Team System 2008 Team Foundation Server, Microsoft IT developed the following best practices that it considers important to the successful deployment of a Team Foundation Server environment:
- Use an incremental upgrade approach. Because Visual Studio Team System 2008 Team Foundation Server supports Visual Studio 2005 clients, Microsoft IT was able to migrate projects and upgrade clients incrementally. Microsoft IT used small teams that worked with each project development team between product releases to minimize any adverse effects of the project migration operation.
- Communicate with product groups to locate unneeded projects. After it deployed Visual Studio 2008, Microsoft IT took advantage of the new functionality in the product to remove unneeded projects. This removal reduced cache size, resulting in improved performance when end-users access Team Foundation Server.
- Use centralized groups to manage permissions. Development teams in Microsoft
IT use Windows® SharePoint® Services as a key part of the team collaboration effort
for each project. However, a Windows SharePoint Services site that is provisioned
via Visual Studio Team System does not mimic the Visual Studio Team System security
permissions. Therefore, permissions that are assigned in Visual Studio may not be
synchronized with permissions that are assigned in Windows SharePoint Services.
To work around this issue, Microsoft IT uses the following process when it creates
a new project:
- It creates new security groups that match the permission groups that are available in Team Foundation Server. For example, Microsoft IT creates a contributors group, a readers group, and a builders group.
- It adds the new security groups to Team Foundation Server, to the project's Windows SharePoint Services site, and to the SQL Server 2005 Reporting Services site.
By using this process, Microsoft IT can manage security permissions from a single location.
Microsoft IT deployed Visual Studio Team System 2008 Team Foundation Server as an upgrade to a successful Visual Studio 2005 implementation. Additionally, support teams deployed Visual Studio 2008 in an incremental manner.
Through this deployment approach, each deployment team experienced specific benefits in its environment. However, the Visual Studio 2008 deployment gave Microsoft IT a greater benefit than the individual deployment teams experienced. This benefit was greater simplification of the whole development system in Microsoft IT, together with an architecture to implement standardized development methods among all the development groups.
By simplifying the development system, Microsoft IT has enabled developers from one group to easily move to other groups. Because the development system and methodologies have become more harmonized among development groups, training costs have decreased and developer productivity has improved.
Program managers throughout Microsoft IT now have greater visibility into the project development environment than was previously possible. By giving managers the tools to view project development from a business perspective, program managers can more easily manage and report on project costs and progress.
Finally, because of the simplification and standardization of source code control in Microsoft IT, overall support costs have decreased.
For More Information
For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:
This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.
©2008 Microsoft Corporation. All rights reserved.
Microsoft, SharePoint, SQL Server, Visual SourceSafe, Visual Studio, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.