Как вы структурируете свои ветки в TFS

Как вы структурируете свои ветки в TFS
Как вы структурируете свои ветки в TFS - borre @ Unsplash

Моя группа на работе пыталась придумать хороший процесс, который мы могли бы использовать с TFS. Мне просто интересно, есть ли у кого-то из вас успешные стратегии использования TFS на нескольких сайтах с использованием нескольких веток.

Одна конкретная проблема, которая у нас есть, вероятно, связана с нашим механизмом выпуска. С простой стороны, разработчик должен иметь возможность регистрировать свои изменения в ветке DEV, а затем согласовывать определенную дату (скажем, дату заморозки), ветка DEV будет «обратно интегрирована» в основную магистраль (QA) в затем изменения будут перенесены в производственную ветку. Проблема возникла, когда пользователь зарегистрировался в ветке DEV, но он не хочет, чтобы эти изменения были перемещены в QA (потому что, возможно, другая часть кода еще не сделана) ... есть мысли по этому поводу?

Я использую его около 4 лет в нескольких разных командах

Я считаю, что для нашей группы лучше всего работает управление ветвями по выпускам/итерациям. Таким образом, все изменения для итерации вносятся в ветку разработки, и когда все они готовы перейти в QA, мы объединяемся.

Это становится небольшой проблемой, если у вас есть что-то в ветке, что на самом деле не готово к слиянию, но тогда вы можете не объединять эти наборы изменений. Это становится грязным, если код, который вы не включаете, меняет какой-то ключевой элемент или что-то еще, но по моему опыту это было редко. Что мы сделали, так это управляли итерациями так, чтобы к концу все действительно было завершено. Если есть часть, которая является рискованной, вы можете сделать ответвление от своей ветки DEV только для этого, чтобы вы могли управлять им отдельно.

Я бы придерживался как можно меньшего количества веток, чтобы вы не тратили много времени на слияние.


LetsCodeIt, 22 мая 2023 г., 22:35