Overview of CA Agile Central TFS Connectors
search cancel

Overview of CA Agile Central TFS Connectors

book

Article ID: 47930

calendar_today

Updated On:

Products

Rally On-Premise Rally SaaS

Issue/Introduction

 

Resolution

Overview of TFS connectors
TFS connector for Work Items:
Overview:
This connector allows one to "reflect" Work Items in TFS with artifacts in Rally, and vice-versa. The connector runs on a Windows computer behind your firewall using Microsoft's TFS (Team Foundation Server) interface and accesses Rally via our Web Service API. Many fields (but not all) can be mapped between the two systems. Note that there are two versions available; one for integration with TFS 2010 and one for TFS 2012
Usage Scenario:
Assume you have 1000 user stories and 300 defects in TFS and you would like to import these into Rally. You also want to be able to update those artifacts across both systems as Rally and TFS users update these artifacts.
Or you may have 1000 user stories and 300 defects in Rally and you would like to import these into TFS. You also want to be able to update those artifacts across both systems as Rally and TFS users update these artifacts.
For example, if the Priority of a defect is changed in TFS, the priority of the corresponding defect in Rally should also be changed by the connector. This means that minimally, in addition to mapping Name fields between the systems, Priority in Rally may need to be mapped to Microsoft.VSTS.Common.Priority. The XML config file needs to be updated as follows to reflect this mapping:
<Field><Rally>Priority</Rally><Other>Microsoft.VSTS.Common.Priority</Other></Field>
We recommend mapping no more than 7 or 8 fields. Some of these fields may be strings, and some may be drop-down fields where each drop-down value in one system needs to be mapped to a corresponding drop-down value in the other system. Some of the fields can be references to objects, and special handling of those fields will be necessary. Some of the fields in Rally system may not have a corresponding field in TFS that lends itself easily to mapping, and consequently a custom field would need to be created in the TFS system for mapping purposes (and vice-versa).
To continue with the Priority field example, this is a drop-down field and the mapping above is necessary but not sufficient if the individual priority values between systems are different. In such a case, this block in the XML config file would be required:
<OtherEnumFieldHandler> <FieldName>Microsoft.VSTS.Common.Priority</FieldName> <Mappings> <Field><Rally>Resolve Immediately</Rally> <Other>1</Other></Field> <Field><Rally>High Attention</Rally>           <Other>2</Other></Field> <Field><Rally>Normal</Rally>                     <Other>3</Other></Field> <Field><Rally>Low</Rally>                         <Other>4</Other></Field> </Mappings> </OtherEnumFieldHandler> 
The integration provided by this connector is customizable, unlike the integration provided by the Visual Studio TFS Plugin, and your XML config file should contain all the custom rules you want for customization.
Also, this connector uses a polling mechanism to determine if an artifact needs to be copied or updated, based on the instructions from the XML config file.
Visual Studio TFS Plugin:
Overview:
This connector supports Visual Studio 2010 in conjunction with TFS Server 2010/2012 with Source Control. Note that the Rally plugin for Visual Studio/Rally Connector for Team Foundation Server is different and independent from the connector described above.
This Visual Studio/TFS plugin installs inside the Visual Studio of a user. The plugin detects the presence of TFS in the user's setup and adds a "Check In/Out" button to the VS plugin. This is the extent of TFS-specific functionality in VS plugin. This plugin is entirely different and completely unconnected to "Rally TFS connector for Work Items".
There is a limitation regarding artifact types in that only Defects and Tasks are supported (i.e. not User Stories). This plugin allows updating of some Rally fields, e.g. ToDo or Actuals fields of Tasks, but otherwise does not copy/update artifacts between systems.
Usage Scenario:
As a developer, a Visual Studio user spends most of their time in Visual Studio. Upon completing a code check-in, the user can change the State of the Task from In-Progress to Complete in Rally, or change the State of the Defect to Fixed, or enter how much time it took to complete the code changes in the Actuals field, all while in Visual Studio, thus eliminating the need to enter this data in the Rally system. These changes in VS/TFS will be automatically propagated to Rally by the plugin.
When both VS and TFS are present on the system, this plugin detects the presence of TFS setup and provides the check-in functionality.
The user can modify these fields of Rally artifacts without leaving Visual Studio:
  • Estimate
  • ToDo
  • Actuals
  • Owner
Also, if any of those values are changed in Rally, when the Rally view in Visual Studio is refreshed, the changes are reflected accordingly.
Note: This connector does not allow the importing/exporting of artifacts from one system to the other.
VCS TFS Connector:
Overview:
The VCS TFS (Microsoft Team Foundation Server) to Rally connector helps you show traceability of code changes to artifacts in Rally.
The connector comprises code that skims a centralized, master TFS repository for recent commits. It extracts information from the commit messages, and posts changeset and change information to a Rally SCMRepository, according to specifications in a configuration file. The connector needs to be installed on only one computer for your company.

Usage Scenario:
A typical workflow would be for one of your team members to be assigned DE42 in Rally. When they make a code change and commit it, they would include text in the commit message like "Found an issue with line breaksfixed DE42". When the connector runs again, it will find that commit message and link the information about the commit to Rally defect DE42.
Developers can put FormattedIDs (such as US42) in their commit messages and the connector will process all commits for configured repositories and pushes information about those commits into changeset objects and change objects in Rally. If a valid FormattedID is found in a commit message, the changeset created by the connector will be associated with that defect, story, or task in Rally.