#visual-studio-2010 #version-control #branching-and-merging #tfs-workitem
#visual-studio-2010 #управление версиями #ветвление и слияние #tfs-workitem
Вопрос:
По вашему опыту, каков наилучший способ указать, где должны быть закодированы рабочие элементы? Используете ли вы определенное поле? В настоящее время мы используем пользовательское поле «Версия для исправления» в нашем WIT, но оно не относится напрямую к разработчикам или основным ветвям кода. В итоге мы сообщаем, какие версии (v6.1, v6.2 и т.д.) Относятся к каким ветвям, Но все еще есть «сопоставление», которое необходимо выполнить. Это действительно работает только для «горячего исправления» в выпущенной версии, потому что ветвь называется так же, как «Версия для исправления». Как назначаются рабочие элементы, чтобы разработчикам было легко узнать, где кодировать, и обеспечивался наименьший объем обслуживания?
Обновлено: просто чтобы немного прояснить… у нас есть ветви Dev, Main и Release (по одной для каждого выпуска). Мы делаем 90% нашей разработки в Dev. Как только итерация заканчивается, мы обратно интегрируем Dev в Main, однако мы не выпускаем его в этот момент. Тестирование некоторое время выполняется на Main, и некоторые ошибки могут быть исправлены на Main. Все это продолжается, пока в Dev продолжается следующая итерация (новые истории). Как только в Main все будет выглядеть хорошо, мы перейдем к новой версии (ветка new Release), и разработка в Main закончится до начала следующей итерации, и мы снова произведем обратную интеграцию в Main из Dev. Конечно, мы перенаправляем интеграцию Main в Dev, как только все исправлено в Main. В любой момент у нас может возникнуть ошибка, которую мы хотим исправить в Dev, Main или в выпущенной версии. Там, где у нас есть исправления ошибок в Main, Dev и Release, мы вводим в заблуждение некоторых разработчиков. Мы сообщаем им «версию», но они должны знать, какая будущая или текущая версия ссылается на какую ветку. Вот где я пытаюсь найти наилучшую практику с рабочим элементом Task.
Ответ №1:
У вас может быть несколько версий (наборов изменений) внутри ветви, но разрастание ветвей — не очень хорошая идея.
Простая (но мощная) стратегия ветвления заключается в создании основного плеча, затем создайте 2 дочерних элемента: 1) Dev, 2) QA Теперь вопрос не в вопросе. Разработчики выполняют свою работу в ветке разработки. Когда они будут готовы, они обратным образом интегрируют изменения в main. Затем изменения перенаправляются в QA. Если сборка проходит проверку качества, то ее можно запустить в производство.
Некоторые организации используют специальные методы ветвления, такие как создание ветви для новой основной версии или даже ветви для специальной функции. Они следуют тому же процессу обратной интеграции в main (и последующей прямой интеграции ветвей разработки, когда это необходимо).
Сборки могут быть связаны с наборами изменений. Если в конкретной сборке есть ошибка, разработчики просматривают номер набора изменений, извлекают его из системы управления версиями, проверяют работу по связыванию его с соответствующими рабочими элементами для исправления ошибки и перестраивают его. Эта новая версия с «исправлением ошибок» теперь имеет уникальный идентификатор сборки и связанный с ней идентификатор набора изменений.
Комментарии:
1. Хотя иметь множество ветвей, возможно, и не является «хорошей идеей», система «Ветвления функций» является совершенно законным способом работы, и есть много SW-магазинов, которые используют эту систему. Среди других преимуществ основным преимуществом является возможность параллельной разработки различных функций без задержек в одной функции, задерживающих выпуск других функций. Как только функция готова, она объединяется с основной ветвью и развертывается. Теперь, учитывая это, когда менеджер R amp; D желает определить новый рабочий элемент, он захочет указать, в какой ветви этот элемент должен быть реализован. Как???
Ответ №2:
Это действительно будет зависеть от вашего магазина; наша среда работает на итеративной сборке, поэтому исправления ошибок всегда попадают в самую последнюю ветку (названную через отметку даты — Т.Е. Branch_05252011 или около того).
Если у вас есть какая-то другая стратегия управления версиями / ветвления, лучшим вариантом было бы поместить желаемую ветвь исправления в заголовок:
V6.2 - Fix the ItExplodedException occuring in SomeClass
В качестве альтернативы, я полагаю, TFS также может предложить специализированный выпадающий список, который вы можете заполнить при создании рабочего элемента с пользовательским содержимым. Затем вы могли бы заполнить это ветвью для назначения.
Ответ №3:
Вот очень эффективное решение: настройте политику возврата с помощью TFS Power Tools и свяжите пользовательскую политику Path с политикой запроса рабочего элемента, чтобы все проверки для ветви требовали ассоциации с рабочим элементом, который попадает в запрос, относящийся к конкретной ветви. Таким образом, если у проверки нет рабочего элемента, соответствующего ветви, это не будет разрешено. Запрос может быть определен с использованием любых необходимых вам критериев, а сами запросы могут быть обновлены и переназначены в разные ветви по мере необходимости.
Однако есть одно предостережение: сами запросы оцениваются на стороне клиента, поэтому как администратор вы можете обновить запрос, чтобы заблокировать или разрешить доступ к определенным элементам в ветке, но разработчикам потребуется обновить Team Explorer, чтобы обновить свой запрос, в противном случае он может разрешить доступ к неавторизованным элементам или заблокировать элементы, которые авторизованы. Одно из решений, которое я ищу для решения этой проблемы, — добавить пользовательскую политику регистрации, которая всегда будет выполняться, но в то же время заставит VS IDE обновить Team Explorer. Я попросил MS добавить это непосредственно в их политику проверки запросов к рабочим элементам TFS Power Tools, но они не ответили.