Создание пользовательской политики «Builds» TFS

Question

Встроенная политика регистрации транзакций TFS не настраивается - она ​​просто смотрит, не сработала ли последняя сборка, и если да, то она показывает предупреждение политики в Visual Studio. К сожалению, он считает, что «последняя» сборка была последней, прошедшей вовремя, а не последней, с последней версией набора изменений. В результате политика может быть прозрачной, даже если все будет нарушено. Рассмотрим такой сценарий:

Джо совершает код в набор изменений 1234, и он начинает строить «Awesome Build» Джон совершает код в набор изменений 1235, и он начинает строить «Потрясающие Build», а также, но изменить набор 1235 содержит перерыв

Поскольку у меня есть несколько агентов сборки, обе сборки запускаются одновременно.

Теперь скажем, что сборка Джона заканчивается первым и терпит неудачу из-за перерыва - политика сборки теперь находится в состоянии Broken - предупреждение о том, что вы не можете проверить (как и ожидалось).

Joe's build завершает второе и успешно - политика построения на этом этапе вернется к четкому состоянию, и предупреждение не появится. (не ожидается, последний набор изменений все еще сломан и должен быть исправлен).

Я знаю, что TFS позволяет мне создавать свои собственные правила регистрации, компилируя класс, реализующий «Microsoft.TeamFoundation.VersionControl.Client.PolicyBase». Есть некоторые вопросы, хотя здесь:

1. только официальной документации я мог бы найти здесь (https://msdn.microsoft.com/en-us/library/bb668980.aspx) и, как следует из страницы, это содержание не является устаревшим и больше не поддерживается. Означает ли это, что существует новый/лучший/более простой способ реализации пользовательской политики регистрации?

2. Кто-нибудь знает, где я могу найти документацию, относящуюся к написанию этих политик, в частности политику «Builds» для решения проблемы, описанной выше. Я бы хотел, чтобы моя политика регистрации была введена в действие на основе последнего набора изменений, а не самого последнего времени сборки.

Любая помощь, которую вы можете дать, будет отличной. Это исправление политики поможет решить многие головные боли в моей очень большой группе разработчиков.

Answer 1

Статья, предоставленная вами, является простым и лучшим способом и применяется к более высокой версии, путь ключа реестра соответствует версии VS (8.0, 12.0 и т. Д.), Для 64-битной машины путь нравится HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ VisualStudio {VisualStudioVersion} \ TeamFoundation \ SourceControl \ Checkin.

В вашей пользовательской политике регистрации вы можете проверить последний результат сборки через TFS API (метод Evaluate). Например:

TeamFoundationServer tfs = new TeamFoundationServer("http://tfsserver:8080/tfs"); 
IBuildServer buildServer = (IBuildServer) tfs.GetService(typeof(IBuildServer)); 
IBuildDetailSpec buildDetailSpec = buildServer.CreateBuildDetailSpec("Team Project", "Build Definition Name"); 
buildDetailSpec.MaxBuildsPerDefinition = 1; 
buildDetailSpec.QueryOrder = BuildQueryOrder.FinishTimeDescending; 
IBuildQueryResult results = buildServer.QueryBuilds(buildDetailSpec); 

Если вам просто нужно, чтобы убедиться, что изменения не вопрос (сборка может быть успеха), а Даниил сказал, что с использованием закрытого типа выезд (TFVC) или тянуть запрос с политикой отрасли (мерзавца).