Политика регистрации TFS - лучшие практики - PullRequest
20 голосов
/ 17 марта 2011

Существуют ли передовые практики для обеспечения соблюдения политики регистрации TFS? Есть ли хорошие руководства о том, как реализовать различные виды политики, а также их плюсы и минусы?

Что мне особенно хотелось бы сделать, это убедиться, что код компилируется (обратите внимание, что компиляция может занимать до пяти минут) и что соблюдаются очевидные биты стандартов кодирования (должны существовать итоговые теги, соблюдаются соглашения об именах и т. Д.) .

Ответы [ 3 ]

17 голосов
/ 17 марта 2011

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 для непрерывной интеграции для выполнения запланированных сборок. Это сводит к минимуму зависимость от минуты к минуте на сервере сборки, одновременно гарантируя (с достаточной эффективностью), что после сбоя сборки мы получим уведомление и сможем исправить ее как можно скорее. Этот метод позволяет разработчикам понять, как интегрировать код и как избежать взлома кода в хранилище.

5 голосов
/ 17 марта 2011

Я думаю, что предпосылка этого вопроса несколько неправильна. Я думаю, что хороший вопрос такого рода должен быть чем-то вроде: у моей команды есть проблема со стабильностью кода, конфликтующими наборами изменений, разработчиками, не выполняющими тесты, плохим покрытием или другими метрическими отчетами руководству и , мы хотели бы использовать TFS, чтобы помочь решить эти проблемы проблемы). Да, я понимаю, что ОП заявил, что обеспечение компиляции считается целью, но это неотъемлемая часть наличия автоматического сервера сборки.

Я бы поставил под сомнение любую особенность, которая добавляет трения в рабочий цикл разработчика без четко сформулированной цели. Хотя я никогда не использовал их, закрытые проверки звучат как функция в поисках проблемы. Если стабильность вашей кодовой базы влияет на производительность разработчика, и вы не можете это исправить, изменив компонетизацию своего программного обеспечения, структуру команды разработчиков или лучшую стратегию ветвления, тогда я думаю, что это решение. Я работал в большом магазине над глобальным проектом, где ClearCase был обязательным инструментом, и я столкнулся с такого рода корпоративным провалом, но команда, над которой я работал, не пошла туда спокойно или охотно.

Идеальная политика - не иметь ее. Пусть разработчики работают без помех и с минимальным трением, насколько это возможно. Обзоры кода делают намного больше, чем набор правил, применяемых бездушным сервером. Команда, которая поддерживает тестирование и имеет правильную структуру, сделает больше для стабильности, чем когда-либо будет достигнута закрытая регистрация. Инструменты, поддерживающие ветвление и локальную регистрацию, позволяют разработчикам пробовать новые вещи, не опасаясь поломать сборку, помогут уменьшить технический долг, который убивает крупные проекты.

4 голосов
/ 17 марта 2011

Обратите внимание на главу 8 «Шаблоны и практики: групповая разработка с Visual Studio Team Foundation Server»

http://tfsguide.codeplex.com/

...