Redmine（またはTrac）と顧客の問題追跡システムの統合
私は大学のソフトウェア開発エリアで働いており、エラーやバグを追跡するために、誰がいつそれを処理するかについて、何らかのシステムが必要であることに気付きました。私はいくつかのソフトウェア管理/バグ追跡アプリケーションを調査しましたが、その単純なUIのためにRedmineが最も魅力的です（実際、私たちのサーバーにはすでにTracがインストールされているシステムが1つありますが、これは使用されていませんその時と私の同僚は私がそれを使用するのと同じ時間がかかると私に言った）。
ただし、同僚からは、中/長期的に顧客の問題追跡システムを実装する考えがあるとのことです（ユーザーの問題のチケットの作成について教えてくれました。一般的な問題の知識ベースを検索し、頻繁に発生する問題にマークを付けて対処します。 [〜＃〜] otrs [〜＃〜] のようなものは、彼が考えていたものに近いようです。彼はITILについても研究しています。
私の知る限り、開発者の問題追跡システムとクライアントの問題追跡システムは異なり、それらの間には何らかの統合が必要です。 またはそうではありませんか？ある場合、私の質問は次のとおりです。
Redmine（または、より簡単であればTrac、または一般にプロジェクト管理/バグ追跡システム）をこの種の顧客の問題追跡システムと統合することは可能ですか？それを実装するために、将来プロジェクト管理システムを変更することについて心配する必要がありますか？または、それらのいくつかを使用すると実装が簡単になりますか？
これはRedmineの観点から書いています。私はTracを使用しておらず、ソースを目でマッサージしただけです（それを読んでさえしていません）。高いレベルでは、Redmineに似ているように思われるので、私が言うことの多くがそれに当てはまるかもしれません。
確認する必要がある最初の質問は、バグ追跡（およびコード変更）側と「顧客が直面する」問題追跡との統合です。別の場所では、他の場所では利用できないある程度の開放性が可能になる場合があります。
- クローズドソースのソフトウェア製品では、コードの変更が、顧客が直面するバグ追跡システムの近くに到達することはできません。一部のコードが取得されるリスクは、それらの多くにとって心配です。
- オープンソースソフトウェア製品は、多くの場合、顧客の問題追跡（同じものです）と並んでソースコードとバグ追跡をホストします。これはRedmineとTracの両方で確認できます。
- アカデミックな設定...まあ、おそらくその中間にあるでしょう。
その最後のポイントが重要です-ソースが出た場合、それは問題ですか？それとも、問題のメモに製品の開発者間の議論が見られたら問題でしょうか？
Redmineには、特定のユーザーが読み取ることを制限する機能があります。プライベートのマークが付けられた個別のメモや、「プログラマーの役割を持つユーザーだけがリポジトリを表示できる」などのメッセージが表示される場合があります。
これが許容できる場合、エンドユーザーの問題追跡とバグ追跡を同じシステムに統合するのが最も簡単です。 「バグ」と「問題」は互いに分離する必要がありますが、それらの間には関係があることに注意してください。エンドユーザーの問題は、バグが原因であるか、エンドユーザーが理解していない問題である可能性があります。
問題とバグのワークフローは異なります。問題は「新規->確認済み->修正待ち->解決済み」のように進む可能性がありますが、バグは「新規->割り当て済み->機能中->コードレビュー->機能中- >コードレビュー->デプロイ済み->クローズ "など。インストールの数と同じ数のワークフローがあります。問題からバグまでの「ブロックされた」関係があると、2つのシステムを簡単に関連付けることができます。
これらすべては、1つのシステムに両方をホストすることが許容できると想定していたため、顧客向けと開発者向けの2つの異なるシステムが見つかります。これにはもう少し作業が必要になる可能性があります-どういうわけか、誰かが2つの間のギャップを埋める必要があります-開発者はバグ追跡システムでエンドユーザーが発見したバグを認識する必要があります。
他の人とうまく機能する最新のバグ追跡システムは見つかりませんでした。すべてが自己完結型であり、商用製品にバグ追跡システムがある場合は、それを簡単に移行して自社製品ライン内のすべてを使用できるようにします。あなたはいくつかのことを可能にするAPIを見つけるかもしれませんが、大部分は-いいえ。
ここでの質問は、ワークロードとは何ですか？2つをどのように統合したいですか（遊びたくない2人の甘やかされて育った子供たちが背中合わせに座っている写真）あるシステムから別のシステムへのリンクがあるだけで十分ですか？新しい問題の量は、これを手作業で実行できるほど少ないのですか？または、一方からポーリングしてもう一方を更新する方法を探る必要がありますか？
2つのシステムを統合するときは、APIを使用するときに、その背後でデータベースを直接更新するのではなく、APIを使用してください。これには危険があります。最新のバグ追跡システムのテーブル構造は非常に大きく、アプリケーションで管理されます。アプリケーションの背後に移動すると、データの整合性に問題が発生する可能性があります。前述のように、データベースで更新して挿入する代わりに、アプリケーションのパブリックAPI（問題に対するRedmineのAPI たとえば ）を使用します。
ビジネスロジックの範囲と統合ポイントは、ジャンプして実行する前に調べる必要があります。データフローのどちらの方法（両方の方法が時々非常に興味深いものになる）とどのデータフロー。バグが特定の状態に達したら、バグに問題をコピーしていますか？同じ問題を何度も作成しないように追跡するにはどうすればよいですか（バグ追跡システムのデータモデルを更新する必要があります）。バグ追跡システムで問題がクローズ済みとしてマークされた場合はどうなりますか？それは逆流しますか？
全体として、おそらく同じシステムを使用してアクセス許可を管理/カスタマイズするのが最も簡単です。開発者からの知識が少しでも漏れていれば、それが深刻な問題ではない場合は、思い通りに機能するようにカスタマイズしてください。
最終的には、これらの間の統合はありません。これらは、「その他の」トラッカーと連携するようには設計されていません。または、彼らがAPIを持っている場合、大規模なエンタープライズショップでない限り、誰もそれをAPIと統合するために誰も使用しません。統合すると、Sharepoint（ため息）のようなものになります。
そのような場合にできる最善のことは、外部バグ追跡への参照を含むすべての内部バグ項目にカスタムフィールドを追加することです。これは手動のプロセスであり、エラーが発生しやすくなりますが、2つを結び付けることができる唯一の現実的な方法です。残りの時間は、それらを個別に使用するだけです。それらの間でデータが交換されることはありません。
同じものを使用できる場合は使用できますが、多くの場所ではこれを実行できず、サポートチームトラッカーと開発チームトラッカーの間には常に接続がありません。