Team Foundation Server 2010 - ветвиться или нет? - PullRequest
Новая
       1

Team Foundation Server 2010 - ветвиться или нет?

1 голос
/ 21 сентября 2011

В настоящее время у меня есть несколько командных проектов, все из которых успешно управляются с помощью TFS.

У меня есть один проект, приложение для Windows, которое в настоящее время используется, и до того, как я перенес базу кода в TFS, мыиспользуется вручную для поддержки как производственной сборки, так и новой сборки разработки с использованием сценариев для копирования / объединения файлов.

например, App1 v1.x - производственная и App1 v2.0 в разработке.

ДоTFS мы вручную «слили» с исправлениями ошибок из сборки разработки в производственную сборку - поэтому, где применимо, исправления ошибок из v1.x также были исправлены в v2.

В этом конкретном случае v2 довольно сильно отличается,пользовательский интерфейс и т. д. Вопрос, который у меня возникает, заключается в том, как лучше всего перенести этот сценарий на TFS.

На мой взгляд, у меня есть два варианта:

  1. Создатьновый командный проект и продолжайте вручную «объединять» соответствующие файлы кода.

  2. Создайте бренд из текущего проекта v1 и замените / замените проект по частям в VS, чтобыУправление исходным кодом может управлять изменениями в главном командном проекте.В V2 также есть несколько дополнительных библиотек классов - если это имеет значение.

Ответы [ 2 ]

3 голосов
/ 21 сентября 2011

Как правило, это стратегия, которую мы используем для ветвления и слияния:

  • Проект начинается.Все члены команды работают над версией 1.0 в одной ветке CURRENT.
  • Проект приближается к вехе или релизу.Создайте ветку, которая будет использоваться для стабилизации кода для производства в ветке PROD 1.0.Теперь половина команды стабилизирует продукт в филиале, а половина команды продолжает делать новые (рискованные) вещи в ветке CURRENT.
  • PROD 1.0 ветка готова и доставлена ​​в производство.Филиал остается неизменным, чтобы обеспечить обслуживание и поддержку доставленной версии.Исправления сделаны в ветке PROD 1.0 и объединены с веткой CURRENT.
  • Проект приближается к другому этапу или выпуску.Создайте новую ветку, которая будет использоваться для стабилизации кода для производства в ветке PROD 2.0.Используется тот же механизм, что и описанный выше.

Используя эту стратегию ветвлений на выпуск, вы всегда имеете ветвь на отправленную и поддерживаемую версию, в которой исправления могут легко распространяться вперед и назад междуверсии и основная линия разработки CURRENT.

В связи с этим мы используем командный проект TFS для нескольких выпусков определенного продукта.Это ограничивает накладные расходы при создании и обслуживании пространств проекта.

2 голосов
/ 21 сентября 2011

Короче ... Разветвление!

Кажется, ваш код между версиями настолько похож, что у вас все будет в порядке, просто разветвив новую версию.

В общем, переход нановый командный проект имеет смысл, если у вас есть одно или несколько из следующего:

  • совершенно новый хлеб требований и / или различные типы рабочих элементов
  • совершенно другая технология, в другихслова, радикально изменившие дизайн, и слияние - это больше потери, чем выигрыш
  • необходимо хранить документы и другие токены на другом сайте SharePoint
  • другая методология разработки - шаблон процесса
  • другойгруппы людей, работающих с обеих сторон, возможно, захотят ограничить пользователей от просмотра v1 или v2
  • планируют выпускать оба продукта в совершенно разных циклах выпуска
  • потребность в полностью разделенных отчетах

Читая твой пост, я не вижу необходимости идти после создания нового командного проекта - конечно, я могу ошибаться.

В случае, если вы решите использовать вариант ветвления, вам может быть очень полезно впечатляющее Руководство по ветвлению TFS для Visual Studio 2010 , о том, как формировать структуру вашей кодовой базы.

...