継続的インテグレーション:ビルドを要件/タスク/バグにどのように結び付けるのでしょうか?
-
04-07-2019 - |
質問
マネージャー、テスター、チーム内の他の人々からの次の質問にどう答えますか。
バグ #829 はどのビルドで修正されていますか?現在のテスト ビルドではどのようなタスクが完了しましたか?
簡単に言うと、要件、タスク、バグの報告から展開までのトレーサビリティをどのように実現するのでしょうか?これを達成するためにどのようなプロセス、ツール、テクニックを使用していますか?
解決
TRAC と SVN を使用して、DEV / STAGING&へのローリングビルドを毎日実行します。生産環境への定期的なスケジュールされた展開(1か月に1回...など)がある安定した環境。
バグが報告されると、TRACに登録され、チケット番号が付与されます(例:#1001)
バグが修正されると、コードはSVNチェックインノートのチケット番号(#1001)でSVNにチェックインされます。
開発者はSVNチェンジセット番号([5000]など)をメモし、TRAC Web UIを開きます。チケットを閉じるとき、彼らはチケットのメモにチェンジセット番号を入れます。
これにより、SVNチェックインはチケットを参照し、チケットはSVNチェックインを参照します。
その後、SVNチェンジセットに対して毎日のビルドが実行され(たとえば、今日のビルドはすべてチェンジセット[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
テストするために修正を確認する際に、テスターは、見ているビルドに修正が含まれているかどうかを、チケットのコメントの変更セットで認識します。
他のヒント
当社では TFS を JetBrains の TeamCity for CI と組み合わせて使用しています。
チェックインをタスクに関連付ける場合、カスタム チェックイン ポリシーは、関連付けられたタスクとバグをその ID とタイトルとともにチェックイン コメントの先頭に追加します。
これらのコメントはリリース ノートの生成に使用され、リリース ノートはビルドごとに自動的に生成されます。
ソース管理チェックインに、修正された欠陥番号または実装された拡張番号をタグ付けしています。
2つのビルド間でチェックインログを取得することにより、何が実装または修正されたかを判断できます。
BeanstalkというマネージSVNサービスを使用します( http://www.beanstalkapp.com/ )これにより、多くのバグ/機能管理システムと簡単に連携できます。私たちのケースでは、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のすべての実装機能のリストを取得するのは非常に簡単です。