Brian Keller, Microsoft Corporation

Summary

Infosys Technologies adopted Microsoft® Visual Studio® 2005 Team System to provide a much-needed upgrade to its enterprise development tools. Infosys realized that Visual Studio Team System would help improve the productivity of their development teams, afford better end-to-end project management capabilities, and would align with their need to remain a CMMI Level 5 development organization. Infosys also identified opportunities to extend and customize Visual Studio Team System to allow better integration with their existing project management tool thereby maximizing team collaboration between project managers and software developers. This article details the integration challenges Infosys overcame during their customization of Visual Studio Team System and serves as a guideline for other organizations considering similar integration and customization scenarios with Visual Studio Team System.

Deployment Goals

As one of the largest software service organizations in the world, Infosys chose Visual Studio Team System not only for the productivity benefits it would enable, but also for its ability to scale to serve over 25,000 developers working on Microsoft technologies within their organization., Key to their Visual Studio Team System integration and customization work is Team Foundation Server. Team Foundation Server provided their development teams with an integrated collaboration solution for enabling change management, work item tracking, reporting, automated builds, and traceability capabilities demanded by a CMMI level 5 organization such as Infosys.

The goals of the project required enterprise-wide scalability and a collaborative platform for the software development team. These goals had to be obtained without making any major (unsupportable) customizations to the out-of-box solution provided by Visual Studio and Team Foundation Server. The principal challenge faced, however, was project managers at Infosys don’t use Visual Studio. Therefore, a key requirement was for Infosys project managers to have a way to interact with the development team while using their in-house project management application, the Infosys Project Management Tool. Integration of the Infosys Project Management Tool with Team Foundation Server became the primary focus for the custom deployment of Visual Studio Team System at Infosys. With this top-level goal in mind, Infosys identified the following sub-components of this project:

• Bi-directional replication of work items.
• Matching UI, workflow, and business rules.
• Remote project creation.

Solution

One of the key capabilities of Visual Studio Team System, including Team Foundation Server, is the ease with which customizations and extensions to an out-of-box solution can be applied. Most of the customizations identified by Infosys were already supported with a documented object model found in the Visual Studio SDK and the Team Foundation Server Administrator’s Guide. It also helped that the Infosys Project Management Tool already supported a service-oriented architecture, which made it easier to develop extensions around the existing solution, as well as a work item tracking infrastructure similar to that found in Team Foundation Server. For help with the remaining customizations, Infosys turned to Microsoft.

Infosys partnered with the Microsoft Visual Studio Team System “Rangers” to help them meet their project goals. The Rangers are a group of consultants within Microsoft who specialize in projects related to Visual Studio Team System. The Rangers work directly with the Microsoft product teams who build Visual Studio Team System. This close working partnership with the product teams enables the Rangers to provide deep consulting expertise to customers such as Infosys.

Achieving Work Item Replication

In order for a project to remain in sync between Team Foundation Server, which the development team interacted with, and the Infosys Project Management Tool, used by project managers, it was necessary to implement a bi-directional synchronization of work items between the two systems. For example, if a developer fixed a defect for which there was a defect work item, that developer would then be responsible for updating the status of that work item in Team Foundation Server. But in order for a project manager to discover that the defect was now resolved, that work item also had to be updated in the Infosys Project Management Tool.

     Figure 1 – This diagram shows an example of the replication which happens when a developer makes a change to a work item in Team Foundation Server  which then gets propagated to the Infosys Project Management Tool.

This bi-directional replication of work items was achieved by first creating an ‘updater’ function, implemented as a Web service, which would be responsible for making updates to the Infosys Project Management Tool. Team Foundation Server already includes a built-in eventing model which allows Web services to be registered as event handlers for a wide range of event types. In this case, it was simply necessary to subscribe the updater Web service to the Change, Update, and Delete (CUD) event associated with Team Foundation Server work items. As soon as a change was made to a work item within Team Foundation Server the Web service was invoked which in turn propagates the necessary changes to the project store within the Infosys Project Management Tool.

The reverse process was also necessary in order to achieve true bi-directional replication between the two systems. Infosys needed to customize the Infosys Project Management Tool so that it would call the same intermediary Web service every time a work item was added or updated by a project manager. That Web service in turn uses the Team Foundation Server object model to make the necessary changes to a Team Foundation Server work item.

Since Team Foundation Server was built with this customization scenario in mind it was fairly straightforward for Infosys to achieve their goal of a bi-directional replication. The only additional step required was to add some logic to the updater Web services which would keep track of which direction each updates was flowing in order to avoid a situation where an endless loop could exist between the two systems.

Matching UI, Workflow, and Business Rules Between Systems

In order to allow developers to make updates to work items in Team Foundation Server it became necessary to implement the same UI, workflow, and business rules which existed in the corresponding forms from the Infosys Project Management Tool. Infosys found that most of their desired customizations could be made by modifying the XML files in Team Foundation Server which describe each work item. The XML schema is documented in the Team

Foundation Server Administrator’s Guide and allows for a wide degree of customizations, including workflow rules, required vs. optional fields, and even the UI layout for working with each work item type. In fact, Infosys estimates that up to 90% of their requirements were able to be modeled in this way. Infosys, working closely with the Team System Ranger team, was able to demonstrate the need for this customization scenario to the Team Foundation Server product team who set to work on a solution. The solution became available with the release of Service Pack 1 for Team Foundation Server 2005. Service Pack 1 provides the ability to embed custom controls as part of a work item form. These custom controls can be authored in C# or Visual Basic using the .NET Framework’s Windows Forms libraries. These custom controls, once authored, could then be inserted into the appropriate work item forms, uploaded to Team Foundation Server, then accessed via Visual Studio when developers accessed a work item form. The custom controls were able to deliver the additional logic required to meet most of the remaining 10% of work item customization requirements at Infosys.

This is the architecture that Infosys settled on for the deployment of this solution and affords them the greatest degree of control over their work items. It is worth noting, however, that the majority of Team Foundation Server users do not require the degree of customization that Infosys did with their deployment. Most customers’ requirements will be satisfied with the out-of-the-box extensibility model provided for work items. A recommended power tool,  the process template editor, is available which can help to graphically design work item forms and the associated forms logic and workflow without requiring direct manipulation of the underlying XML.

Security Considerations

Another challenge which Infosys needed to address was that of ensuring that the synchronization between Team Foundation Server and the Infosys Project Management Tool did not introduce security breaches. For example, there is a risk that a low-privileged user in the Infosys Project Management Tool might achieve higher privileges in Team Foundation Server. To address this concern Infosys implemented programming logic in the custom controls on the work item forms.

Allowing Remote Project Creation

Team Foundation Server uses the term “Team Project” to refer to a software development project. A Team Project includes source control, work items, reports, build configurations, security settings, and other artifacts related to a given project. A new Team Project is usually created by a developer working within Visual Studio using the Project Creation Wizard. The Project Creation Wizard prompts the developer for a variety of inputs such as the project name and the process template to be used for this project. The challenge for Infosys, however, was that project managers, not developers, were responsible for the initial creation of a project. Since project managers don’t use Visual Studio it therefore became necessary to extend the project creation capabilities of Team Foundation Server to be integrated with the Infosys Project Management Tool.

Infosys again worked closely with the Team System Ranger team to devise a solution. Since the Project Creation method is contained in a DLL file, the Rangers collaborated with the Team Foundation Server product team to determine how the functionality in this wizard could be safely called from the Infosys Project Management Tool. The appropriate Project Creation method was then wrapped as a Web service to be called by the Infosys Project Management Tool. By leveraging the existing project creation logic contained in the Project Creation Wizard this drastically reduced the amount of work required as opposed to re-implementing this functionality within the Infosys Project Management Tool. Microsoft has since made this functionality available as a Team Foundation Server Power Tool release.

Implementing Transaction Support

The initial deployment phase outlined above gave Infosys the confidence they needed that Team Foundation Server would meet all of their objectives for integrating with their Project Management Tool. But in order to make their deployment truly robust and enterprise-scalable Infosys identified the need to add transactional support to the replication solution. After the initial deployment, Infosys added such transaction and fault tolerance support to the integrated solution by utilizing Microsoft Message Queuing (MSMQ). The exact implementation details of adding transaction support are beyond the scope of this paper, but the concepts of such a system are summarized here.

Ideally, each change is performed within a single transaction. However, at Infosys, a change in either Team Foundation Server or the Infosys Project Management Tool required a corresponding change in the other system (to support the bi-directional replication discussed earlier). Supporting transactions across multiple systems such as this is commonly referred to as a distributed transaction. With a distributed transaction model a change made in one system should only succeed if the corresponding change was successful in the second system. If the change failed in either system then the change would be rolled back and neither system would be updated; the person who tried to make the change would be notified of the failure, and both systems would stay in their original (pre-transactional) state. Unfortunately, in many cases, a distributed transaction is not always possible or practical. One reason may be if a high degree of latency exists when attempting to perform an update to the other system. It may therefore be undesirable to expect a user to wait while an update is verified across both systems. When a distributed transaction model is impractical or impossible, compensation logic may be used instead.

Although a compensation logic is sometimes referred to as the poor-man’s version of distributed transaction support, it is a widely used mechanism, especially in long lived transactions. If an attempt to apply an update to the second system fails, error-handling will execute the compensation logic which reverses the update in the first system. This happens as a separate step and as a result, the user may not be notified immediately of the failure. Though not as convenient or as timely as short lived transaction, it at least allows the two systems to remain in sync.

Another consideration for such a replication system is to enable a system reset procedure. Despite having compensation logic in place there may still be a scenario where data becomes out of sync between the two systems. One way to implement a system reset would be to designate one system as the lead system and use that to recreate all of the data on the secondary system. This could be used as a last resort to correct a system failure and put the system back into a consistent state.

Additionally, any system which relies on such a replication model may benefit from tools and processes which can help verify the integrity of data between two systems and flag any discrepancies. It may also be useful to enable an audit trail which logs replication events. This audit trail can be analyzed later to help debug the root causes of any discrepancies. Having this level of traceability is an important element to compensating transactions.

Team Foundation Server Migration and Integration Solutions

The solution described in this whitepaper required Infosys to create a synchronization engine, define mappings, and create custom logic in order to achieve 2-way synchronization between the Infosys Project Management Tool and Team Foundation Server. Microsoft has subsequently released toolkits and libraries which can facilitate some of this work. The Team Foundation Server Migration and Integration Solutions page on MSDN includes information about several such packages. An example of one such package, the Team Foundation Server Migration and Synchronization Toolkit, uses a provider model to allow for the synchronization or migration of Team Foundation Server source control or work items with other such systems. Developers can author custom providers for the toolkit in order to synchronize or migrate data between Team Foundation Server and other systems.

Conclusion

Through this initial deployment Infosys was able to prove that Team Foundation Server had the extensibility support required to successfully integrate with their existing Infosys Project Management Tool. The bulk of the customizations required by Infosys were already supported with a documented object model, and the remaining requirements were met by enlisting the help of the Team System Rangers working in concert with the Microsoft product groups responsible for building Visual Studio Team System. With the addition of a distributed transaction model to the bi-directional replication engine, Infosys expects to deploy Visual Studio Team System and Team Foundation Server to over 25,000 developers working on Microsoft technologies within the organization over the next few years.

As a result of adopting Visual Studio Team System at Infosys and integrating Team Foundation Server with the Infosys Project Management Tool, Infosys integrated its engineering life cycle and IT project management processes while minimizing overall development costs. The organization was also able to extend its product capability to provide better product integration and improve team productivity. For more information about the direct and indirect benefits of this adoption please view the case study: Infosys Demonstrates Project Management Integration with Visual Studio Team System.

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.

© 2008 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.