Структура разработки Team Foundation Server - PullRequest
Новая
       39

Структура разработки Team Foundation Server

1 голос
/ 07 июня 2011

Я являюсь частью небольшой команды разработчиков, которая находится в процессе перехода от Visual Source Safe к TFS2010.

Я читал о структуре TFS и наткнулся на очень хорошовопрос.

Одна вещь, упомянутая в приведенной выше ссылке, в которой я не уверен, это структура разработки: 

- Development/
      - Trunk/
          - Source/
          - etc/
      - Branches/
          - Source/
          - etc/

Я не очень понимаю необходимость в Trunk и Branches как отдельные дочерние контейнеры для Development.Как я читаю эту структуру, Trunk будет переходить от Integration (или Main, если вы используете терминологию MS), а Branches будет затем переходить от Trunk (то есть Trunk является родительским для несколькихBranches).

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

- Development/
      - DevBranchOne/
          - Source/
          - etc/
      - DevBranchTwo/
          - Source/
          - etc/

В приведенной выше структуре (где DevBranchOne и DevBranchTwo заменены значимыми именами) ветки разработки - это братья и сестры, и все ветки от Integration (или Main).Учитывая вышеизложенное, мои вопросы:

  1. Правильно ли мое понимание предполагаемого использования Trunk в Development?
  2. Если ответ на мой первый вопрос - даВ чем преимущество реализации такой иерархии в Development?
  3. Является ли использование Trunk просто чем-то, что перенесено из SVN (с которым у меня нет опыта)?

Ответы [ 2 ]

0 голосов
/ 08 июня 2011

Я бы не рекомендовал использовать этот другой вопрос в качестве модели. Похоже, они сворачивают несколько ветвей функций в ветку интеграции («Магистраль») и затем дополнительно интегрируются в еще одну ветку интеграции («Интеграция»). Это похоже на разветвленную систему, предназначенную для соответствия их существующему рабочему процессу - хотя в этой системе нет ничего плохого, она не вписывается в мой рабочий процесс, и вам придется изменить свою для принятия.

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

Если вы еще этого не сделали, обязательно ознакомьтесь с рекомендациями по ветвлению TFS в Visual Studio ALM Rangers.

0 голосов
/ 07 июня 2011

Я согласен, в сообщении, на которое вы ссылаетесь, он обнаружил, что у него есть 2 "ствола", "Развитие \ Транк и Интеграция", что является еще одним названием для ствола в его контексте.

В зависимости от стратегии ветвления обычно требуется только один «ствол» (или ветвь интеграции).

Однако есть некоторые сценарии, в которых вам может потребоваться несколько ветвей интеграции, например, если вы делаете что-то вроде ветвления за функцией, но у вас также есть концепция групп функций, где различные ветви функций должны быть интегрированы вместе в группа функций перед интеграцией в ветвь интеграции подсистемы, которая впоследствии будет интегрирована в основную ветвь интеграции продуктов (она также является транком).

Однако для большинства стратегий ветвления требуется только одна ветвь интеграции.

...