Блокировка шаблона управления процессом TFS? - PullRequest
6 голосов
/ 05 мая 2009

Моя команда стремится перевести многие из наших инструментов (SCM, отслеживание ошибок, сборки, тестирование) на TFS. Мы рассматриваем перемещение каждой системы поэтапно. Например, сначала переместите управление исходным кодом, затем отслеживайте ошибки / функции и т. Д. *

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

Я знаю, что теоретически могу настроить все, что шаблон процесса настраивает после факта (верно?), Но насколько это возможно на практике?

Вот как я вижу происходящее:

  1. Мы переносим наш исходный код. Мы выбираем шаблон CMMI от Microsoft.
  2. Мы создаем новый рабочий элемент (или уведомление о регистрации), который представляет собой простую ссылку на нашу устаревшую систему отслеживания ошибок.
  3. Мы работаем некоторое время.
  4. Мы ждем до полномочий, которые будут (мы - софтверная компания приличного размера), чтобы разработать новый рабочий процесс разработки TFS. Это может быть простая коллекция новых рабочих элементов или совершенно новый шаблон, который настраивает все виды вещей.
  5. Мы пытаемся перенести наш проект TFS в эту новую систему без потери нашей истории.

Будем ли мы сожалеть, что мы не подождали, пока все эти решения не будут завершены, прежде чем использовать TFS?

1 Ответ

9 голосов
/ 05 мая 2009

Итак, вы правы, думая о шаблоне процесса, поскольку существует определенное количество «блокировок», однако оно не слишком серьезное. Как будто вы застряли в своем шаблоне процесса с медом, а не супер клеем.

Лично я бы начал с шаблона MSF Agile. Он намного легче и содержит меньше рабочих элементов, поэтому вам, скорее всего, захочется добавить к нему что-то (очень легко в TFS, очень хорошо поддерживается), а не убирать их (более сложно и не совсем удовлетворительно).

Тем не менее, если власти, которые решат перейти на процесс определения убер-процесса и волшебным образом придумают новый шаблон процесса через 12 месяцев, который они хотят, чтобы вы использовали, тогда он не будет полностью потерян. Если вы обнаружите, что хотите создать новый командный проект, если он находится на этом сервере (или в Project Collection в TFS 2010), вы можете либо перенести свой код в новый командный проект (что означает, что история несколько скрыт в текущих версиях клиентов TFS) или вы можете создать новый командный проект с пустой папкой для контроля исходного кода, а затем переместить дочерние папки из старого командного проекта в новый. Это прекрасно сохранит историю, поскольку TFS поддерживает историю перемещений в одном и том же экземпляре TFS. Тем не менее, ваши рабочие элементы до переезда будут застревать в старом шаблоне процесса, и вам нужно будет решить, хотите ли вы скопировать их или просто оставить их, чтобы они закрылись естественным образом.

Очевидно, что при использовании TFS в течение 12 месяцев в реальных проектах, когда возможности, которые придут, сбивают вас с толку, вы также окажетесь в гораздо лучшем положении, чтобы узнать, как вы хотите, чтобы ваш блестящий новый шаблон процесса выглядел - Я часто обнаруживал, что это - упражнение, которого никогда не бывает, и большинство людей с удовольствием возятся по краям MSF Agile или выбирают что-то более предписывающее, например Scrum For Team System .

Надеюсь, это поможет,

Martin.

...