4

チケットシステム（またはバグ追跡）をSVNと統合するソフトウェアがあるのだろうかと思っていましたが、特定の方法で. チケット (またはバグ ID) を持たないコード変更を禁止したい。

例えば：

  1. 各開発者は SVN への読み取り専用アクセス権を持っています。ソースを更新することはできますが、コミットすることはできません。
  2. 各コミットにはバグ/チケット ID が含まれている必要があります
  3. 最適化タスクであっても、開発者は自分用にチケットを作成し、いくつかのものを実装する必要があります

チケット システムと SVN の統合に役立つ Mylyn のようなツールがあることは知っていますが、開発者はいつでもソースをコミットできます。

チケット システムの環境はありません (Trac や BugZilla などを使用できます) が、コード リポジトリとして SVN を使用する必要があります。

これらのサービスをこのように統合する方法について何かアイデアはありますか?

4

3 に答える 3

3

私は最近TFSを使用しています。これには、同様のワークフローを設定する機能があります。バグを添付し、変更をコミットできる「作業項目」を作成する必要があります。最初にバグを作成せずに、最初に作業項目を作成せずにコミットすることは不可能です。

私のワークフローは次のようになったので、それは私を夢中にさせ、設定を変更しました：

  • 喜んでコードを編集してバグを修正します。
  • 別の無関係なバグを見つけます。
  • コードの変更を最初のバグにコミットします。
  • フローを停止し、ワークアイテム エディターを起動します。
  • VS2010 のひどい作業項目の UI を把握し、新しい作業項目を作成します。
  • VS2010 の恐ろしいバグ トラッカーを見つけ出し、新しいバグを作成します。
  • コードに戻ります。
  • 2 番目のバグがどこにあったかを調べます。
  • 2 つ目のバグを修正します。
  • 元のバグの作業に戻ります。

実際、私のワークフローは次のようになりました。

  • 喜んでコードを編集してバグを修正します。
  • 別の無関係なバグを見つけます。
  • 「そのコード行を修正するには、鈍いバグトラッカーをいじるのにかなりの時間がかかります。それをやめてください。」.
  • 元のバグに取り組み続けます。

全体的な結果として、ばかげた官僚的なバグ報告システムで時間を無駄にするつもりはなかったので、すぐに修正できたはずのバグがシステムに残っていました。あなたにとってどちらが重要ですか? 幸せで生産的な開発者と、SVN から引き出された見栄えの良いレポートとは?

于 2011-01-04T14:56:55.550 に答える
3

この種のポリシーでは、ログ メッセージにチケット ID があるかどうかをチェックするフック スクリプトを記述し、もちろんチケット ID が適切なプロジェクトに属しているかどうかをチェックする必要があります。さらに、 Redmineなどをチケット システムとして使用できます。

于 2011-01-04T16:02:14.707 に答える
0

本当にやりたい場合は、ユーザーがバグのリストを表示できるようにする亀のプラグインである gurtle を見ることができます。そのテンプレートに従って、ケース/問題がない場合に、迅速かつ簡単にケース/問題を作成する方法を提供できます。

私が言わなければならない形はさておき、あなたの目標は間違った方向に進んでおり、非生産的だと思います。いくつかの善意のあるプロセス/ポリシーは、時には良さそうに見えますが、実際には悪夢であり、時間とリソースの浪費に終わります。これは、時間の無駄と悪いプロセスの良い例です。

于 2011-01-04T15:13:18.203 に答える