2

アプリケーションで (作業中に) 例外がスローされたときに、誰を「責める」べきかを特定する方法を作ろうとしています。もちろん、それは私が引き起こしている可能性がありますが、私はそれを受け入れることができます:)。しかし、これを行うには、例外の行で最後に誰が変更を行ったかを確認できるように、TFS のファイルの履歴が必要です。もちろん、誤った変更が挿入された例外の行に常にあるとは限らないため、おそらく同じファイルへの変更と、最後に最近行われたチェックインも確認する必要があります。これをどのように解決するかはわかりませんが、これに対する既存の解​​決策があるかどうか、最初にコミュニティに確認したいと思いますか? 私はまだ TFS API の経験がないので、何が可能で何が不可能かを判断する方法がありません。これを未処理の例外ハンドラーでアプリに統合すると思います。例外の候補が見つかったら、メールで通知する必要があります。その過程で、特定の例外がイントラネット上のユーザーによってスローされた回数、誰が、いつ、どのようにスローしたかなどをログに記録すると便利です。これにより、多くの時間 (およびお金) を節約できます。

4

2 に答える 2

5

私は精神が好きです！TFS APIは非常に強力であり、関心のある情報をあらゆるレベルで取得できます。

  • アプリを作成し、アプリをTFS APIアプリと呼んで、プログラムでTFSに接続する方法を確認できますhttp://geekswithblogs.net/TarunArora/archive/2011/06/18/tfs-2010-sdk-connecting-to -tfs-2010-programmaticallyndashpart-1.aspx。

  • TFS APIを使用すると、ファイルに加えられたすべての変更（変更セット）についてTFSにクエリを実行できます。したがって、たとえば、ClassAbc.csで例外が発生し、TFS APIアプリケーションに対してこの例外を発生させるイベントバスがある場合は、versionControlService GetChangesetメソッドのメソッドを使用して、そのファイルで実行されるすべての変更セットを取得できます。ここでそれを行う方法を確認してくださいhttp://geekswithblogs.net/TarunArora/archive/2011/06/26/tfs-2010-sdk-smart-merge-programmatically-create-your-own-merge.aspx。

  • この時点で、2つのチェンジセット間でデルタを実行し、次のようなものを使用してコードの変更を取得できます。

    public static void GetMergeDetailsForChangeSet()
{
    var tfs = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri("Enter the url of team project"));
    var versionControl = tfs.GetService<VersionControlServer>();


    var a = versionControl.GetChangeset(12322);

    VersionSpec changeSpec = new ChangesetVersionSpec(a.Changes[0].Item.ChangesetId);

    var abc = a.Changes[0].Item.VersionControlServer.QueryMergesWithDetails(
        null,
        null,
        0,
        a.Changes[0].Item.ServerItem,
        changeSpec,
        a.Changes[0].Item.DeletionId,
        changeSpec,
        changeSpec,
        RecursionType.Full);

}

  • 実際のコードができたので、そのコードブロックに対して一連のStyleCop http://www.codeproject.com/KB/cs/StyleCop.aspxルールを実行し、考えられる例外や一般的なコード分析結果を見つけることができます。データベースに記録され、ユーザーに電子メールで送信されます。

興味深いですね。ただし、代わりに、TFSのAnnote機能を使用して、ファイルに対して開発者が行った一連の変更を確認し、コード分析をCIビルド定義に関連付けて、チームの開発者が行ったコード変更について常にフィードバックを得ることができます。

于 2011-06-30T22:33:21.957 に答える
1

これは本当に理にかなっていますか？例外がスローされた時点での変更によって、どの程度のシナリオで例外が発生するかを検討してください。通常、例外の理由は、スロー時のコールスタック内のどこかにあります。99% のシナリオで役に立たないことに時間を費やすべきではありません。

于 2011-06-30T08:48:56.923 に答える