TFS - устойчивость каскадных ветвей - PullRequest
Новая
       74

TFS - устойчивость каскадных ветвей

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

В руководстве по ветвлению обычно описывается бессмертная ветвь "Main" с функциями, ответвленными от Main и объединенными обратно с Main, и версиями Releases с Main, с дальнейшими ветвями Release по мере необходимости для пакетов обновления, окончательных версий и т. Д. РуководствоЧто касается Main, его часто упрощают до «без мусора в Main».

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

enter image description here

Ежедневные сборки на ветке сделаны;в конце концов отрасль переходит на производство.Любые исправления для ветки применяются непосредственно к этой ветке и, при желании, объединяются с любыми будущими ветвями в полете.

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

Является ли эта практика каскадных ветвей в TFS устойчивой в течение длительного периода времени.Если нет, то каковы пределы и когда (после скольких ветвей) они могут быть достигнуты?

Есть ли какая-либо причина, чтобы НЕ "уничтожать" Main, R1, R2 (и т. Д.) В конце концов, или есть "недочет", который предотвратит уничтожение и освобождение пространства на сервере SQL, на котором размещен источникхранилище кодов?

1 Ответ

4 голосов
/ 02 сентября 2011

Каскадные ветви могут работать. Я также не могу придумать каких-либо технических причин, по которым уничтожение очень старых (предпочтительно архивированных) веток может повлиять на более новые каскадные ветви. Вот некоторые вопросы для рассмотрения:

  1. Разработчики должны сопоставлять новую ветвь со своим рабочим пространством после каждого выпуска.
  2. Разработчики должны вручную переместить любую работу в новую ветку, если они не смогли зарегистрировать ее перед выпуском (вместо простой проверки в той же рабочей ветке Dev или Main после выпуска).
  3. Если у вас есть один или несколько разработчиков, работающих в дочерней ветви Rn, и принято решение перенести их работу на Rn + 1, то потребуется необоснованное объединение, чтобы избежать проверки в исходной родительской ветви Rn.
  4. УБЕДИТЕСЬ, ЧТО ВЫ БЕЗОПАСНО ЗАБЛОКИРУЙТЕ КАЖДЫЙ ФИЛИАЛ после выпуска. Все эти ветки увеличат риск того, что разработчик случайно проверит изменения в выпущенной ветке.
  5. Вам необходимо настроить определения сборки и любые другие специфичные для пути артефакты после каждого каскада. Если вся разработка работает только из Dev (или Main), то основное рабочее пространство и связанные с ним артефакты сборки / проекта остаются неизменными со временем.
  6. Как вы работаете с параллельными объектами в изоляции, когда вы не знаете, какие функции будут поставляться в Rn? (Если у вас есть основная ветвь, у вас может быть несколько дочерних ветвей разработчика функций из Main, тогда объединяйте ветку функции только тогда, когда она стабильна и готова к объединению для отправки в следующем выпуске.)

Я полагаю, что Джефф Левинсон сделал презентацию, которая описывала эволюцию ветвления, начиная с одной ветви, затем каскадной ветви, затем Main + Release и пары вариантов (при описании плюсов и минусов каждого). Ознакомьтесь с Практики ветвления и слияния - Джефф Левинсон (Teched 2010 Video) (или связанный Ветвление и слияние PPT ).

Наслаждайтесь! -Zephan

...