マネージャー、テスター、およびチーム内の他の人々からの次の質問にどのように答えますか。
バグ #829 はどのビルドで修正されていますか? 現在のテスト ビルドで完了したタスクは何ですか?
簡単に言えば、要件、タスク、およびバグのトレーサビリティを、レポートのレポートからデプロイまで、どのように実現するのでしょうか? これを達成するために、どのようなプロセス、ツール、テクニックを使用していますか?
マネージャー、テスター、およびチーム内の他の人々からの次の質問にどのように答えますか。
バグ #829 はどのビルドで修正されていますか? 現在のテスト ビルドで完了したタスクは何ですか?
簡単に言えば、要件、タスク、およびバグのトレーサビリティを、レポートのレポートからデプロイまで、どのように実現するのでしょうか? これを達成するために、どのようなプロセス、ツール、テクニックを使用していますか?
当社ではSVNでTRACを使用し、DEV / STAGING & STABLE 環境への毎日のローリング ビルドを実行し、定期的にスケジュールされた (月に 1 回... っぽい) 本番環境への展開を行います。
バグが報告されると、TRAC に入力され、チケット番号 (例: #1001) が割り当てられます。
バグが修正されると、コードは SVN チェックイン ノートのチケット番号 (#1001) で SVN にチェックインされます。
開発者は SVN Changeset 番号 ([5000] など) をメモし、TRAC Web UI を開きます。チケットをクローズするとき、変更セット番号をチケットのメモに入れます。
このように、SVN チェックインはチケットを参照し、チケットは SVN チェックインを参照します。
その後、毎日のビルドが SVN Changeset に対して実行されます (たとえば、今日のビルドはチェンジセット [5050] までのすべてです)。これについては、デプロイ通知に記載されています。
Deployed On | Environment | Changeset
--------------+-------------------------+--------------------------
10-01-2008 | DEV | 5100
10-01-2008 | STAGING | 5080
10-01-2008 | STABLE | 5050
01-01-2008 | PRODUCTION | 5000
こうすることで、テスターは、テスト用の修正を確認する際に、チケット コメントの変更セットによって、見ているビルドに修正が含まれているかどうかを知ることができます。
CI には、JetBrains の TeamCity と組み合わせて TFS を使用します。
チェックインをタスクに関連付ける場合、カスタム チェックイン ポリシーは、関連付けられたタスクとバグの ID とタイトルをチェックイン コメントの先頭に追加します。
これらのコメントは、ビルドごとに自動的に生成されるリリース ノートの生成に使用されます。
ソース管理チェックインには、修正された欠陥番号または実装された拡張番号をタグ付けしています。
2 つのビルド間のチェックイン ログを取得することで、何が実装または修正されたかを判断できます。
Beanstalk ( http://www.beanstalkapp.com/ ) と呼ばれる管理された SVN サービスを使用して、多数のバグ/機能管理システムと簡単に結び付けることができます。私たちの場合、その目的のために Fog Creek の FogBugz を使用します。SVN/Beanstalk を使用すると、ビルドをチェックインするときにメモを作成できます。これは、1 つまたは複数のFogBugzケースのステータスに影響を与えます。
クライアント側では、Tortoise SVN と Visual SVN を使用してローカル クライアントと Beanstalk SVN サーバーのやり取りを管理します (Tortoise は実際のサービスを提供し、Visual SVN は Tortoise SVN と MS Visual Studio の統合を提供します)。
サービスと Tortoise/Visual SVN クライアントの両方を強くお勧めします。
Subversion 統合が組み込まれた Fogbugz を使用しています。基本的に、バックグラウンドで SVN チェックインをチェックする Fogbugz 用のプラグインがあります。そのため、チェックイン時に Fogbugz-case id を指定すると、このチェックインに自動的にリンクされます。
私の知る限り、特別なアプリケーションは必要ありません (Beanstalk など)。
その逆は少しトリッキーです。私たちの会社では、すべての (将来または過去の) ビルドに対して Fogbugz に「リリース」があるという規則があります。バグを修正したり、機能を実装したりする場合は、ケースを適切なリリースに割り当てます。
次に、ビルド X のすべての実装機能のリストを取得するのは非常に簡単です。