複数のプロジェクト間で共有されているライブラリの問題を追跡する必要があります。これらのコンポーネントを共有する方法はありますか? それとも、影響を受けるプロジェクトごとに個別の問題を提出した方がよいでしょうか?
4 に答える
これを回避するには、共有コード用に別のプロジェクトを作成し、関連するリリースに応じて各課題にタグを付けてから、課題のリストを追跡するために複数のプロジェクトにわたってこれらのタグを参照する JIRA フィルターを作成します。リリース。
たとえば、製品 A と製品 B があり、どちらも共有ライブラリを使用しているとします。製品 A のバージョン 1 と製品 B のバージョン 2 をリリースしたい。これらのリリースは両方とも、共有ライブラリ プロジェクトの問題 1001 を修正する必要があります。
共有ライブラリの問題 1001 に「ProdAVer1 ProdBVer2」のタグを付け、バージョン 1 のすべての製品 A の問題に「ProdAVer1」のタグを付け、バージョン 2 のすべての製品 B の問題に「ProdBVer2」のタグを付けます。次に、製品 A のすべての問題、または製品 A リリースの問題を追跡するためのタグ「ProdAVer1」を含む共有ライブラリを含むフィルターを作成し、製品 B についても同様にタグ「ProdBVer2」を使用します。
これは、私が書き留めた今では少し長くなってしまいましたが、複数のプロジェクトで複製された課題を使用するよりも優れたオプションだと思います。
共有コードでも同じ問題に遭遇します。現在、「クローン」を使用して複数のプロジェクトで問題を作成しながら、それらの間の接続を維持していますが、理想的なソリューションとは言えません。
この問題に関連するJIRA の JIRA プロジェクトには一連のチケットがあります。そこにアカウントを設定すると、問題に投票して開発チームに影響を与えることができ、チケットが更新されたときに通知を受け取ることができます。
おそらく JIRA を使い続けるつもりなので、これはおそらくすぐには役に立ちませんが、これはLaunchpadのバグ追跡によって提供される大きな革新的な機能であることを指摘しておく必要があると思いました。開発者は、さまざまなオープンソース アプリケーションのバグが共有ライブラリの共通のバグに要約されることが多いことに気付き、1 つの問題を複数のプロジェクト、バージョン、およびリリースに添付する方法を開発しました。