Есть ли какие-либо рекомендации по обеспечению соблюдения политики регистрации TFS? Есть ли хорошие руководства о том, как реализовать различные типы политик, а также их плюсы и минусы?
Мне особенно хотелось бы убедиться, что компиляция кода (обратите внимание, что компиляция может занять до пяти минут), и соблюдаются очевидные биты стандартов кодирования (должны существовать сводные теги, соглашения об именах и т.д.),.
TFS 2010 (и 2008, но я не использовал 2008) разрешает стробированную проверку - которая заставляет сборку до проверки сборки.
Активация этого (разумного) простого процесса, см., например, следующие руководства: http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx http://intovsts.net/2010/04/18/the-gated-check-in-build-in-tfs2010/
Есть шаг перед всем этим, что необходимо для того, чтобы все это произошло. Это настройка сервера сборки TFS. Это может быть сложный процесс в зависимости от инфраструктуры и т.д. Вот руководство MSDN: http://msdn.microsoft.com/en-us/library/ms181712.aspx
Плюсы в том, что код в репозитории может быть достаточно стабильным. Для большой команды это может сэкономить много времени.
Есть много недостатков, которые стоит рассмотреть для этой выгоды. Во-первых, установка и обслуживание дополнительного сервера сборки. Это включает выделение дискового пространства, исправления и т.д. Во-вторых, дополнительное время, необходимое каждому человеку для проверки файла. Ожидание успеха сборки до того, как код будет проверен (и доступен для других), может быть некоторое время. В-третьих, когда (если нет) сервер сборки недоступен, должен быть предусмотрен план на случай непредвиденных обстоятельств, чтобы позволить разработчикам продолжать свою работу.
Существует много дополнительного процесса, необходимого для получения вознаграждений за закрытые проверки. Однако этот процесс правильно регулируется, он может привести к значительно более плавному циклу разработки.
Хотя мы не используем закрытые проверки, мы используем сервер сборки TFS для непрерывной интеграции для выполнения запланированных сборок. Это минимизирует зависимость от минуты на минуту на сервере сборки, обеспечивая при этом (с разумной эффективностью), что после сбоя сборки мы уведомляемся и можем исправить ее как можно скорее. Этот метод дает разработчикам возможность понять, как интегрировать код, и как избежать нарушения кода в репозитории.
Я думаю, что предпосылка этого вопроса несколько неправильна. Я думаю, что хороший вопрос такого характера должен быть чем-то вроде этого; моя команда испытывает проблемы с стабильностью кода, конфликтующими наборами изменений, разработчиками, не выполняющими тесты, плохой охват или другой метрической отчетностью для управления, и мы хотели бы использовать TFS, чтобы помочь решить эту проблему (проблемы). Да, я понимаю, что ОП заявила, что обеспечение компиляции считается целью, но это является частью и пакетом с автоматическим сервером сборки.
Я бы задал вопрос о любой функции, которая добавляет трение к циклу работы разработчика без четко сформулированной цели. Несмотря на то, что я никогда не использовал их, строчные проверки звучат как функция для поиска проблемы. Если стабильность вашей кодовой базы влияет на производительность разработчика, и вы не можете ее исправить, изменив компонентную комплектацию вашего программного обеспечения, структуру команды разработчиков или лучшую стратегию ветвления, я думаю, это решение. Я работал в крупном магазине в глобальном проекте, где ClearCase был мандатным инструментом, и я столкнулся с такой корпоративной неудачей, но команда, над которой я работала, не ходила туда спокойно или охотно.
Идеальная политика - не иметь ее. Пусть разработчики работают без ограничений и с минимальными трениями, насколько это возможно. Кодовые обзоры делают гораздо больше, чем набор правил, которые будут выполняться бездомным сервером. Команда, которая поддерживает тестирование и правильно структурирована, будет делать больше для стабильности, чем когда-либо достигнутая регистрация. Инструменты, которые поддерживают разветвление и локальную проверку, упрощают разработчикам пробовать новые вещи, не опасаясь разбить сборку, помогут смягчить техническую задолженность, которая убивает крупные проекты.
Вы должны ознакомиться с главой 8 "Шаблоны и методы: Team Development с Visual Studio Team Foundation Server"