Architecture Recommendation for Defect Tracking Integration

1. Introduction

This document recommends the architecture for integrations of Perforce Software's fast software configuration management system with defect tracking systems.

The readership of this document is Perforce senior management.

This document is not confidential.

2. Executive Summary

I recommend that the project use the replication architecture [GDR 2000-05-08, 3.2].

3. Summary of Analysis

This is a copy of the conclusions section of [GDR 2000-05-30].

3.1. Replication architecture

Does not enforce consistency between the defect tracker and Perforce. This means that organizations using the integration in combination with undisciplined development will suffer from inconsistencies which need human attention to resolve [GDR 2000-05-30, 2.1.1].

Is decoupled from both the defect tracking system and the Perforce server (in the sense that it uses public interfaces to both). This means that it is cheaper to maintain and cheaper to adapt than either the single-database or union architecture [GDR 2000-05-30, 2.21.1, 2.29.1, 2.35.1].

Can use open, interpreted and portable languages for easy customization [GDR 2000-05-30, 2.24.1].

Does not need very much of Chris Seiwald's time [GDR 2000-05-30, 2.76.1].

The Perforce server is changed: a relation between jobs and filespecs is added, a field is added to the fixes relation indicating the meaning of the fix, the Perforce API is extended to support these additions, and a post-change triggers is added to all operations that change the Perforce database [GDR 2000-05-30, 2.76.1].

Co-operation is needed from defect tracking vendors to make sure that their tracker-client operations (as replicated back to the defect tracker's database) don't conflict with their own changes to the database [GDR 2000-05-30, 2.1.1].

3.2. Single-database architecture

Requires major changes to the Perforce server and hence too much of Chris Seiwald's time [GDR 2000-05-30, 2.76.2]. Consequently it is costly to maintain and support [GDR 2000-05-30, 2.35.2].

Installation and configuration will be tricky because of the need to make modifications to the Perforce server which will change between platforms [GDR 2000-05-30, 2.63.2].

It's risky for a company that is already using Perforce jobs to migrate to using the integration because the jobs need to be copied to the defect tracker's database and it may be hard to get them back again if the installation is ever unintalled [GDR 2000-05-30, 2.64.2].

Hard to implement using open and easily configurable technology - for performance, and because it interfaces directly with the Perforce server, it is in C or C++ [GDR 2000-05-30, 2.82.2]. Therefore it is hard for others to adapt [GDR 2000-05-30, 2.21.2].

Can't cope with organizations that use multiple defect tracking systems [GDR 2000-05-30, 2.97.2].

3.3. Union architecture

Expensive and risky to develop [GDR 2000-05-30, 2.76.3]. Requires considerable database expertise to solve the problems of distributed transactions [GDR 2000-05-30, 2.1.3]. The distributed transactions will impose a considerable performance cost on the whole system [GDR 2000-05-30, 2.1.3].

Expensive and risky to port to each new database [GDR 2000-05-30, 2.21.3].

Because of the complexity of the software, the integration will be costly to maintain and support [GDR 2000-05-30, 2.35.3].

Hard to install and administer, because it interferes with the normal operation of company database applications, which connects to the unifier rather than directly to the database, and because it interferes with the normal operation of the Perforce server, for which a new version or configuration is installed [GDR 2000-05-30, 2.63.3], [GDR 2000-05-30, 2.64.3].

Hard to implement using open and easily configurable technology - for performance it is in C or C++ [GDR 2000-05-30, 2.82.3]. Therefore it is hard for others to adapt [GDR 2000-05-30, 2.21.3].

Can't cope with organizations using multiple Perforce servers [GDR 2000-05-30, 2.96.1] or multiple defect tracking systems [GDR 2000-05-30, 2.97.1].

3.4. Tracker-client architecture

The tracker-client architecture does not support defect resolution using Perforce's interface [GDR 2000-05-30, 2.41.4] so is combined with one of the other architectures for the project to succeed.

The Perforce client API is well documented in order for defect tracking vendors and others to be able to implement interfaces to Perforce [GDR 2000-05-30, 2.21.4].

Defect tracking vendors need to develop an interface to Perforce changelists in order for developers to be able to record the reason for their changes [GDR 2000-05-30, 2.39.4], [GDR 2000-05-30, 2.44.4].

Defect tracking vendors need to develop an interface that allows developers to branch and merge files associated with a task [GDR 2000-05-30, 2.53.4].

Defect tracking vendors need to develop an interface allowing an analyst to record the nature of the association between a file and a task [GDR 2000-05-30, 2.55.4].

4. Conclusions

A. References

B. Document History

Copyright © 2000 Ravenbrook Limited. This document is provided "as is", without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this document. You may make and distribute verbatim copies of this document provided that you do not charge a fee for this document or for its distribution.