プロジェクトで使用するバグ/問題追跡システムを選択しています。 この質問とこの質問は、評価するシステムを提供するのに役立ちます。しかし、提供されているさまざまな製品を調べて質問があります。
一部のシステムは、機能としてソースコード管理システムの統合を促進します。これは私が以前に使用したものではなく、さまざまなツールのWebサイトを見ると、この統合が提供するものの詳細を正確に見つけることができません。バグを発生させるために使用するのと同じWebインターフェイスを介してリポジトリを参照するだけですか？
では、そのような統合にはどのようなメリットがありますか？どのように時間を節約したり、製品を改善したりできますか？
JiraとFishEye (SCM ブラウザー) を併用すると、"PROJ-123" などの Jira 課題キーを含むログ メッセージを含む変更セットをコミットする場合、対応する Jira 課題にリンクを挿入すると、Jira はリンクを表示します。 PROJ-123 で、その問題に言及している変更セットに。
Jira はHudsonと統合することもできるため、修正を組み込んだビルド (変更セットなど) が実行されると、そのコミットのログ メッセージに記載されている Jira 課題がビルドのステータスに関するコメントを取得します。
課題トラッカーはソース コードの問題を追跡するために使用されるため、統合された課題/ソース管理システムで想像できる機能が大量にあります。
私はこれを Visual Studio Team Foundation Server で行いました。これは、ソース管理と統合するだけでなく、データ ウェアハウスとも統合します。これにより、たとえば、どのバグがどのコードによって引き起こされたのかを追跡し、どのコードがより多くの QA を必要とするかを示すことができます。2010 年版の今後の機能は、さらに魅力的です。
主な利点は、ソース コードの特定のリビジョンに対してバグを報告できることです。これは、バグが発見されたときのコードベースの状態を特定するのに役立ちます。この分野で人気のある製品は、SVN と統合されたTracだと思います。
ここには大きな理由が 1 つあります。それは、タスク/問題指向の方法で作業できるからです。
つまり：
あなたが行うすべてのコード変更 (小さなクイック修正から大きな新機能まですべて) は、Jira、Rally、Bugzilla、Trac、Mantis など、好きなもので問題になります。
これは、問題/タスク追跡システムが使いやすく、高速で、シンプルでなければならないことを意味します。そうでなければ、開発者はそれを嫌います
次に、すべての変更を課題に関連付ければ完了です。完全なトレーサビリティ (diff のデバッグに最適です。これがないと見逃してしまいます)、プロジェクト追跡の改善、リリース管理の改善などが得られます。
各変更セット/コミット (scm の専門用語に応じて) をタスクにリンクするか、scm がそれを実行できる場合は、バグ修正ごとにブランチを作成できます。これはさらに優れています。
基本的に得られるものは単純です。すべての変更が文書化されるか、少なくとも適切な課題/タスクにリンクされます。
ブランチを使用する場合は、次のようなことを促進できます: 常に安定したベースラインで作業する、メインラインの破損を減らす (または、必要に応じて元の状態にする)、統合するタスクと次のリリースまで保持するタスクを決定する、変更前に個別にテストを実行する合流など。