Объединение командных проектов

Question

В нашем текущем проекте у нас есть четыре различных командных проекта TFS2010 в одной коллекции командных проектов. Причина этого в том, что разные части проекта хотели использовать разные шаблоны командных проектов (CMMI против Agile).

Все проекты теперь используют один и тот же шаблон. Поэтому мы пришли к выводу, что было бы лучше объединить проекты в один командный проект. Это поднимает несколько вопросов:

1. Возможно ли / возможно ли использовать один из существующих проектов в качестве целевого проекта для остальных трех?
2. Как мы перемещаем наши существующие рабочие элементы в новый проект, сохраняя при этом наше дерево областей? Мы надеемся создать одну корневую область для каждого из наших существующих командных проектов и переместить все рабочие элементы / области под этот корневой узел.
3. Сегодня у нас есть ссылки на рабочие элементы из одного командного проекта в другой - как мы сохраняем эти ссылки при объединении?
4. Какова лучшая практика при перемещении исходного кода? Один из четких подходов - просто скопировать его в новое место, а также заблокировать и сохранить старые командные проекты на случай, если нам понадобится доступ к более старым версиям кода. Но возможно ли использовать для этого разветвление, например, Разветвление всего существующего кода в новый командный проект? Какие проблемы могут возникнуть при таком подходе?

Спасибо за вашу помощь!

Answer 1

К сожалению, TFS 2010 не позволяет объединять командные проекты.

Структурирование групповых проектов и коллекций командных проектов является одним из наиболее важных стратегических решений, которые необходимо принять перед началом использования TFS.К сожалению, многие клиенты, которым мы помогаем, не нуждаются в предварительном планировании и не понимают некоторые ограничения в TFS, связанные с объединением, перемещением, разделением и т. Д. Командных проектов, прежде чем они начнут погружаться в использование TFS:(

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

В конечном итоге«миграция» не приводит к переносу всей информации, и вы сталкиваетесь с некоторыми другими проблемами, такими как отметки даты / времени, которые отличаются от того, чем они были изначально (я слышал, что это называется проблемой сжатия времени смиграции.)

SВот некоторые дополнительные мысли по каждому из ваших первоначальных вопросов:

1. Конечно, вы можете теоретически использовать один из существующих командных проектов в качестве цели для миграции остальных трех.Если вам нравится имя командного проекта и вы не хотите переименовывать командный проект .:)
2. Здесь мы создали собственные утилиты миграции рабочих элементов, чтобы помочь нашим клиентам-консультантам.Скорее всего, вам придется сделать то же самое.
3. Это возможно и с помощью специальной утилиты миграции рабочих элементов.Вы можете просто отслеживать соответствия между старыми идентификаторами рабочих элементов и новыми идентификаторами рабочих элементов, а затем добавлять ссылки позже, как только все новые рабочие элементы будут созданы в целевом командном проекте.
4. В конечном счете, это зависит от вас.,Я бы сделал «перемещение» операции контроля версий на исходном коде из старого командного проекта в новый командный проект.Это поддерживает все.Однако я бы не стал удалять ни один из старых командных проектов, потому что это также приведет к уничтожению истории управления версиями.

Это не лучшая история для вас, но, надеюсь, она поможет вам в планированиинекоторые!