| Introduction | ||
|---|---|---|
|
|
|
|
| User Guide Contents | Installation | |
For organizations needing to connect development, QA, and project management, the Tasktop Sync solution provides the only enterprise-scale ALM middleware solution, built on the industry-standard Eclipse Mylyn ALM integration framework. Tasktop Sync provides two distinct capabilities: Task Linking and Task Synchronizing. In addition, Tasktop Sync also provides a Quick Start to help configure repositories.
Unlike previous approaches to ALM synchronization, Tasktop Synchronizing provides real-time synchronization, automated conflict resolution, and support for over two dozen ALM tools. Building on Tasktop’s Task Federation™ technology, Tasktop Sync’s synchronization component ensures that each stakeholder has access to the data that they need within their tool of choice, even if the data resides across requirements management, Agile development and traditional quality management systems. Task Synchronization Configuration will explain how to configure the Task Synchronization feature.
For those who want a lighter-weight solution, Tasktop Sync’s Task Linking enables traceability by letting you find and link related tasks across repositories with minimal configuration. Task Linking is built on top of Open Services for Lifecycle Collaboration (OSLC) protocols, an industry-standard means for communicating between ALM components. Sync supports the service provider, picker, links, and preview features of the OSLC Core 2.0 standard. This means that Task Linking allows users to select, link to and preview related tasks in a foreign repository from a OSLC consumer’s system. Not only can Task Linking communicate with OSLC consumers (like IBM RTC RRC 3.0.1 and IBM RTC CCM 3.0.1) easily, Tasktop Sync connectors can turn HP ALM and Quality Center, JIRA, and TFS repositories into OSLC producers. Task Linking Configuration will explain how to configure the Task Linking feature.
Tasktop connects to many different products, and different vendors and products have very different terms for similar concepts. It is important to understand these terms to make sense of the rest of this manual.
Task — A task is an item of work that someone needs to act upon. Many things in other products are what we call tasks, defects, bugs, feature requests, work items, test cases, trouble tickets, records, etc. This can be confusing. For example, IBM RTC manages “tasks”, “work items”, and “defects”, all of which we call “tasks” in this document.
Repository — A repository (or “task repository”) is a collection of tasks. In other products, what we call “repositories” or “task repositories” are also called bug databases, bug trackers, issue tracking systems, incident tracking systems, etc.
Proxy Task — As Tasktop Sync synchronizes tasks between repositories, a proxy relationship between synchronized tasks is defined. A proxy task is the task (say, Task O) in the other repository that is synchronized to the current task (say Task C). Conversely, Task C is the proxy task of Task O.
Task attribute — A task attribute is an aspect of a task that is stored in a repository. “Date” and “Priority” are common task attributes. In other products, what we call “task attributes” are also called fields, columns, etc.
Task attribute values — A task attribute value is the specific value that a task attribute may have. For example, “March 14, 1:59am 2011” might be a task attribute value for the task attribute of “Date”. “P1” might be a task attribute value for the task attribute of “Priority”.
Connector — A connector is the software that connects Tasktop Sync to a repository. Different vendors' repositories use different connectors.
The integration visualizer provides the user with a broad overview of the ALM architecture configured in Tasktop Sync. This view not only allows the overall ALM architecture to be understood quickly, but it also provides a easily understood snapshot of the health of the architecture by tracking and display synchronization history and highlighing problems between different parts of the architecture.
Tasktop Sync provides a comprehensive UI for configuring synchronization mappings between pairs of repositories and tasks. The task mapping editor allows users to quickly define new mappings, as well as add to and modify existing mappings.
Tasktop Sync automatically handles conflicts in an intelligent fashion.
Conflicts can occur when two synchronized tasks are updated at the same time in each repository. If two users are collaborating on the same task and decide to update it at the same time, they might submit incompatible changes. For example, one user could change the priority of the task to “High” while the other user changes it to “Medium”. Most repositories provide built-in support for handling this case, but this support only works for tasks being accessed on the same repository. In a synchronized environment, the tasks can exist in different repositories; only Tasktop Sync is in a position to handle conflicts that occur across repositories.
Heterogeneous ALM repositories often accessed by different groups, with varying degrees of overlap. Even in the cases where the same user is accessing both systems being synchronized, the user might have different user IDs in both systems. For example a user might be called joesmith in one repository and jsmith in another. Synchronizing data between repositories involves translating these IDs between repositories so identities are preserved.
Tasktop Sync provides a pluggable system for mapping person IDs. For simple person ID mappings Tasktop Sync can be pointed at a file containing the mappings between person IDs. A default person ID can be provided on each repository that is used if a user exists in one system but not the other.
Tasktop Sync stores all important task related data in your existing task repositories. There is no information stored in Tasktop Sync that is not retrievable from one of the repositories participating in synchronization. This means that utilizing Tasktop Sync does not cause your data to be stored in a new properietary format, nor do you need to back up task data from the machine running Tasktop Sync.
This section describes the overall architecture of Tasktop Sync. Understand the fundamentals section makes Tasktop Sync configuration easier. The follow sections are more advanced discussions of the architecture of some of the critical features of Tasktop Sync.
At its core, Tasktop Sync maintains synchronization between a task in one repository, say Task A, with a task in another repository, say Task 1. In this case, Task 1 is called the “proxy task” of Task A, and vice versa.
The architecture of Tasktop Sync involves pairs of connectors to task repositories. These connectors provide a common interface to Sync for accessing tasks from that repository. Sync then uses these connectors in its core to synchronize tasks between the two connectors. This modular architecture is what enables Tasktop Sync to easily work with many different vendors' repositories and create general mappings between any pairs of these supported repositories.
The tasks which are synchronized between pairs of repositories are scoped by queries. These queries allow Sync to bound the set of tasks which should be synchronized between repositories, but it also allows Sync to build a local cache of task data to improve both throughput and latency of task synchronization, but also allows Sync to resolve conflicts between tasks at a fine-grained level.
Sync uses these queries to issue requests to each repository to identify changed tasks which require synchronization. Synchronizations can be batched by varying the a delay which Sync uses between checking its queries for changed tasks.
Tasktop Sync is optimized to minimize latency, maximize throughput, and minimize load on your repositories.
Together, his means that the synchronization speed does not depend upon the size of your repository or the number of users, only on the frequency of meaningful changes.
The first step in handling conflicts is to detect them. This may seem obviously easy, but consider that there’s a difference between two tasks being out of sync with each other and being in conflict with each other. If an attribute of the two tasks is different because one of the tasks has been updated while the other wasn’t, that is not a conflict. If the attributes are different because they have both been updated at the same time, that’s a conflict. Furthermore, if an attribute of both tasks has been updated at the same time with the same change then they have in effect been synchronized by the users, then there is no conflict; a synchronization action would be redundant. If two tasks have changed, but the attributes which changed were different in the two tasks, again, there is not actually a conflict. For example, if one person changed the Severity of a task to “BLOCKER”, while another person changed the owner to “mgarcia”, this would not be a conflict.
If a synchronizer only has information that two tasks were updated at the same time, but not information about which attributes caused the tasks to conflict, then that synchronizer will not be able to recognize non-conflicting attribute changes. Tasktop Sync, however, can detect which attributes have changed, and thus provides built-in support for attribute-level conflict detection.
Once a conflict has been detected, the next step is to decide what to do about the conflict. This involves selecting one of the changes as the new value of the attribute, thus overwriting the other value, or deciding that the sync is not allowed to go through at all and leaving both values in place. Note that with attribute-level conflict detection only changes to the same attribute are declared as conflicts and chosen to be resolved. Non-conflicting changes to different attributes are merged and both tasks are updated with the other’s changes.
Tasktop Sync has the following policies available for resolving conflicts:
Conflict resolution policies can be defined at both the task level and the attribute level in the configuration file. Defining a conflict resolution policy at the task level applies that policy to every attribute mapping defined in that task’s mapping that does not have its own resolution policy. Conflict resolution policies specified in an individual attribute mappings apply only to that attribute and override the policy specified in the containing task mapping.
Once a conflict has been detected and resolved, then it’s often useful for users to be notified of the conflict and what action was taken to resolve it. At a minimum, Tasktop Sync reports all conflicts in a log file available to Sync administrators. However, Sync administrators are often not in the best position to act on this information as they may not be involved in the task on which the conflict occurred. It’s often desirable for the users who are subscribed to the task to be notified of the conflict so they can confirm that the action taken was appropriate, or at least be aware that two users were posting conflicting data to a task.
Sync provides a conflict notification policy whereby the conflicts will be logged in the comment stream of the task in question. The comment indicates which attributes were involved in the conflict and which values were overwritten according to the conflict resolution policy.
|
|
|
|
| User Guide Contents | Installation |