TFS 2010 - у нас есть ветки кода. Каков наилучший способ сказать разработчикам, какую ветку кодировать?

Question

Каков ваш лучший способ определить, где должны быть закодированы рабочие элементы?Вы используете конкретное поле?В настоящее время мы используем настраиваемое поле «Версия для исправления» в нашем WIT, но оно не имеет прямого отношения к Dev или ветвям кода основной строки.В итоге мы сообщаем, какие версии (v6.1, v6.2 и т. Д.) Относятся к каким ветвям, но все еще существует «отображение», которое необходимо сделать.Это действительно работает только для «Hot Fix» в выпущенной версии, потому что ветка названа так же, как «Version to Fix».Как рабочие элементы обозначены так, чтобы разработчикам было легко знать, где кодировать и обеспечить наименьшее количество обслуживания?

Обновлено: просто для пояснения ... у нас есть Dev, Main и Release (одинза каждый выпуск) ветки.Мы занимаемся 90% нашего развития в Dev.Когда итерация завершена, мы интегрируем Dev в Main, но не выпускаем ее в этот момент.Тестирование выполняется на Main некоторое время, и некоторые ошибки могут быть исправлены на Main.Все это продолжается, пока следующая итерация (новые истории) продолжается в Dev.Как только все будет хорошо на Main, мы перейдем к новой версии (новая ветвь Release), и разработка на Main закончится, пока не начнется следующая итерация, и мы снова не обратимся к интеграции с Main из Dev.Конечно, мы переходим к интеграции Main в Dev, когда все исправлено на Main.В любой момент у нас может быть ошибка, которую мы хотим исправить в Dev, Main или в выпущенной версии.Там, где у нас есть исправления ошибок в Main, Dev и Release, мы путаем некоторых разработчиков.Мы говорим им «версию», но они должны знать, какая будущая или текущая версия ссылается на какой-либо филиал.Вот где я пытаюсь найти лучшую практику с рабочим элементом задачи.

Answer 1

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

Простая (но мощная) стратегия ветвления состоит в том, чтобы создать главную ветвь, а затем создать 2 дочерних элементов: 1) Dev, 2) QA. Теперь вопрос не является вопросом.Разработчики делают свою работу в ветке Dev.Когда они готовы, они в обратном порядке интегрируют изменения в основной.Затем изменения будут интегрированы в QA.Если сборка проходит QA, она может быть развернута в производство.

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

Сборки могут быть связаны с наборами изменений.Если в конкретной сборке есть ошибка, разработчики ищут номер набора изменений, вытаскивают его из системы контроля версий, проверяют работу, связывая ее с соответствующими рабочими элементами для ошибки, и перестраивают ее.Эта новая версия «исправления ошибок» теперь имеет уникальный идентификатор сборки и идентификатор набора изменений, связанный с ней.

Answer 2

Вот очень эффективное решение: настройте политику регистрации с помощью TFS Power Tools и свяжите политику настраиваемого пути с политикой запроса рабочего элемента, чтобы для всех проверок для ветви требовалась связь с рабочим элементом, который попадает в отраслевой запрос. Таким образом, если в проверке нет рабочего элемента, соответствующего ветви, это не будет разрешено. Запрос может быть определен с использованием любых критериев, которые вам нужны, и сами запросы могут быть обновлены и переназначены различным ветвям по мере необходимости.

Одно предостережение: сами запросы оцениваются на стороне клиента, поэтому как администратор вы можете обновить запрос, чтобы заблокировать или разрешить определенные элементы в ветви, но разработчикам потребуется обновить Team Explorer, чтобы обновить их запрос. в противном случае он может допускать несанкционированные элементы или блокировать разрешенные элементы. Одним из решений, которое я ищу для этой проблемы, является добавление настраиваемой политики регистрации, которая всегда будет выполняться, но в то же время заставит VS IDE обновить Team Explorer. Я попросил MS добавить это непосредственно в политику проверки запросов рабочих элементов TFS Power Tools, но они не ответили.

Answer 3

Это действительно будет зависеть от вашего магазина;наша среда работает на итеративной сборке, поэтому исправления ошибок всегда идут в самую последнюю ветку (названную с помощью отметки даты - IE Branch_05252011 или около того).

Если у вас есть какая-то другая стратегия управления версиями / ветвления, лучшим вариантом будет поместить нужную ветку исправлений в заголовок:

V6.2 - Fix the ItExplodedException occuring in SomeClass

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