2

製品 (project1、project2、...) 間で共有されるコア ランタイムと、プロジェクト/製品固有の部分で構成される製品を開発します。これらの「製品」ごとに、複数のブランチを維持しています。これは、さまざまなバージョンがフィールドに展開され、メンテナンスが必要であり、バックポートを備えている場合もあるためです。

問題追跡システムとして JIRA も使用していますが、製品タイプ/ブランチをモデル化する正しい方法を見つけるのに苦労しています。このコンテキストに関連すると思われる JIRA 要素は、コンポーネントとバージョンです。

  • コンポーネントを使用して、CORE、PRO1、PRO2 などを区別します。
  • コンポーネントを使用して、関係するブランチを特定します
  • 修正バージョンを使用して、問題を解決するためのイテレーションを追跡します (イテレーション開発、隔週イテレーション)

これは多かれ少なかれ機能しますが、ブランチに Component タイプを使用することはハックであり、コンポーネントを「廃止」することはできず、削除することしかできないという欠点があります。反復とブランチを [修正バージョン] フィールドに混在させると、「反復 X とブランチ Y」をクエリできなくなるため、この方法を選択します (JIRA は AND クエリをサポートしていません)。

JIRA でブランチを維持し、イテレーションを追跡するためのベスト プラクティスにはどのようなものがありますか?

コンテキストの統計: 約 4 つの製品タイプと、製品タイプごとに約 3 つの主要なブランチを維持することについて話しています。

4

2 に答える 2

3

私はこの問題に対して少し異なるアプローチをとります。コア ランタイムと各プロジェクト/製品固有のパーツ用にコンポーネントをセットアップしますが、これらのコンポーネントをブランチ固有にはしません。したがって、Jira プロジェクトには次のコンポーネントが含まれている可能性があります。

  • 芯
  • 製品X
  • 製品Y
  • 製品Z

次に、さまざまなブランチをバージョンごとに区別します。私は、フィールド内のバイナリを特定のブランチとバージョンに結び付けることができる、ある種のバージョン番号付けシステムを持っていると仮定しています。バージョン/ブランチごとに Jira でバージョンを設定します。問題を Jira に報告する場合、影響を受ける 1 つ以上のバージョンを選択できます。

このシステムにはいくつかの利点があります。

  1. 問題が複数のバージョン/ブランチにまたがる場合、問題の影響を受けるすべてのバージョンを特定できます。
  2. バージョンの修正を 1 つ以上のバージョンに設定できます。場合によっては、トランクまたは特定のブランチの問題のみを修正することがあります。おそらくそれは大きな問題であり、ブランチ間で修正を移植する必要があります。このシステムにより、そのすべてを確認してレポートする柔軟性が得られます。
于 2009-11-20T13:22:25.770 に答える
0

私が考えることができる簡単なアプローチの1つは、イテレーション名にブランチ名（および場合によってはプロジェクト名も）を含めることです。次に、修正バージョンを使用して、branch1_iteration1、branch1_iteration2、branch2_iteration1などの名前で反復とブランチを示すことができます。

これにより、ブランチ内の特定のイテレーションの問題についてクエリを実行できます。また、各修正バージョンに対して期日を設定できるため、スケジュールどおりかどうかを追跡できるという利点もあります。

余談ですが、プロジェクト（CORE、PRO1など）を示すためにJIRAコンポーネントフィールドを使用するのではなく、代わりに個別のJIRAプロジェクトを使用します。そうすることで、より優れた粒度と柔軟性が得られます。

于 2009-05-22T17:01:38.677 に答える