Это скорее вопрос для обсуждения, который не относится к типу вопросов, которые обычно требуются StackOverflow, но я укушу.
Политики, которые для меня имеют смысл:
- Политика сборки
- Эта политика предотвращает очередь сборки неудачных сборок после того, как кто-то прервет сборку.На самом деле вы будете предупреждены о том, что сборка в настоящий момент повреждена, поэтому кто-то может исправить сборку, прежде чем продолжить.
- Ассоциация рабочих элементов
- Нам нужна ассоциация рабочих элементов, чтобы гарантироватьмы можем проследить, чтобы проверки выполнялись через тестовые случаи.
- Запрос рабочего элемента
- Мы хотим, чтобы люди выбирали свою работу из текущего спринта / итерации.Таким образом, удобно проверить, что работа, с которой проверяются люди, на самом деле является предварительно одобренной работой.
- Политика пользовательских путей
- Мы используем этовремя от времени политика в командах проектов, которые содержат более одного проекта и где мы хотим повысить качество или безопасность одного проекта, но не заинтересованы в том, чтобы беспокоить другой проект.Или для предотвращения определенных проверок в текущей ветке выпуска, но не хотим таких строгих политик для старой версии, которая все еще поддерживается.
Мы проверяем несколько вещей, которыевы можете сделать это посредством политик регистрации, отказав в сборке CI.Это делается главным образом для экономии времени на компьютерах разработчиков.
- Политика анализа кода.
- Вместо того, чтобы использовать для этого политику регистрации, мы используем сборку CI, которая не будет работать, если нарушены определенные правила анализа кода.Это позволяет нам позволить сборкам разработчика пропускать анализ кода при каждой сборке.Люди довольно быстро узнают, как предотвратить запуск этих правил в любом случае.
Мы не используем никакой другой политики.Комментарий Require для политики набора изменений - это то, что мы иногда используем, но большинству команд на самом деле не нужна политика для этого через некоторое время.Отсутствие комментариев по поводу регистрации осуждается большинством, и это решается само собой.
У нас было несколько проектов, в которых было выполнено отслеживание времени (для CMF MSF), и мы использовали пользовательскую политику , чтобы обеспечить людейобновляли свои часы при каждой регистрации .
Мы не используем никаких политик для принудительного применения покрытия кода или количества предупреждений.Их можно добавить в сборку, если необходимо, с помощью настройки процесса сборки.
Мы используем проверенные проверки в ветвях, которые требуют дополнительной проверки.Такие как ветки выпуска и ветки, за которыми следует автоматическое развертывание.
Мы часто позволяем разработчикам обходить любую политику регистрации без штрафа.То же самое касается закрытых Checkins.Разработчик должен использовать эти права с умом.Нарушение развертывания - это то, что вы не можете делать слишком часто, пока вас не заметит команда;).
Существует также несколько интересных пользовательских политик, но я знаю только несколько людей, которые на самом деле зашли так далеко.как их использовать.
- Политика слияния только
- Эта политика позволяет указать пару ветвей, которые могут получать только слияния уже проверенных в работе наддругая ветвь.
- Политика запрещенных шаблонов
- Я иногда использовал их, чтобы убедиться, что нет
/bin/debug, .exe или .dllбыл проверен в папке //src/ в TFS.
Есть еще несколько политик от третьих лиц, но я никогда не использовал их.К ним относятся:
- Пакет политик регистрации и на этой странице перечислены несколько дополнительных политик, которые мне никогда не приходилось использовать.
Одна из причин, по которой не следует использовать слишком много сторонних политик, заключается в том, что всем членам группы должны быть установлены политики на их компьютерах. Team Foundation Server Power Tools может помочь вам с распределением, но они не развернуты и не настроены на всех рабочих станциях разработчиков по умолчанию.
Также доступно в виде блога .