Я пытаюсь каким-то образом выяснить, кого «винить», когда в нашем приложении (на работе) возникает исключение. Конечно, это может быть из-за меня, но я могу принять это :). Но для этого мне нужна история файла в TFS, чтобы я мог проверить, кто последним внес изменения в строку исключения. Конечно, не всегда в строке исключения было вставлено ошибочное изменение, поэтому мне, вероятно, также потребуется проверить любые изменения в том же файле и, наконец, любые проверки, сделанные совсем недавно. Я не уверен, как я это сделаю, но я хотел бы сначала узнать у сообщества, есть ли какие-либо уже существующие решения для этого? У меня пока нет опыта работы с TFS API, поэтому я не могу сказать, что возможно, а что нет. Думаю, я бы интегрировал это в наше приложение в обработчик необработанных исключений. Когда некоторые кандидаты исключения найдены, мне нужно сообщить им по электронной почте. В процессе было бы неплохо записывать, сколько раз какое-либо исключение вызывалось каким-либо пользователем в нашей интрасети, кто, когда, как и т. д. Это могло бы сэкономить нам много времени (и денег).
Получите историю изменений файлов из TFS, чтобы реализовать собственное поведение исключений
Ответы (2)
Мне нравится дух! API TFS очень мощный, и вы можете перейти на любой уровень глубины для получения интересующей вас информации.
Вы можете создать приложение, давайте назовем ваше приложение приложением TFS API, проверьте, как вы можете программно подключиться к TFS http://geekswithblogs.net/TarunArora/archive/2011/06/18/tfs-2010-sdk-connecting-to-tfs-2010-programmaticallyndashpart-1.aspx.
API TFS позволяет запрашивать у 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.
На этом этапе вы можете сделать дельту между двумя наборами изменений и получить изменения кода, используя что-то вроде этого.
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 в отношении этого блока кода и при обнаружении возможных исключений или общие результаты анализа кода могут быть записаны в базу данных и отправлены пользователю по электронной почте.
Звучит интересно. Но, в качестве альтернативы, вы можете использовать функцию Annote в TFS, чтобы увидеть ряд изменений, внесенных разработчиком в файл, и связать анализ кода с вашим определением сборки CI, а также получать постоянную обратную связь об изменениях кода, внесенных разработчиками в вашей команде.
Это действительно имеет смысл? Подумайте, в скольких сценариях исключение вызвано изменением в момент его создания. Обычно причина исключения находится где-то наверху или даже не в стеке вызовов во время броска. Не стоит тратить время на то, что не поможет вам в 99% случаев.
