Ищем схему ветвления TFS, которая поддерживает интегрированную ветвь тестирования - PullRequest
3 голосов
/ 06 октября 2011

Мы рассматриваем возможность перехода с SVN на TFS, поэтому я пытаюсь найти подходящий рабочий процесс, который будет использоваться в TFS для удовлетворения наших потребностей.Существует множество обсуждений схем ветвления, но большинство из того, что я видел, имеет одну общую черту, которая не соответствует нашим потребностям;почти все схемы ветвления предполагают, что ваши ветки тестируемы.

Итак, мы создаем некоторые ветви функций из магистрали:

Trunk --(branch)--> Feature1
Trunk --(branch)--> Feature2
Trunk --(branch)--> Feature3

В нашем случае мы создаем ветви функций, каждая ветвь функций можетбыть проверенным модулем, но может не быть проверенным QA.Это потому, что каждая ветвь функций должна иметь свой собственный экземпляр БД и веб-сервер, и у нас просто нет ресурсов для этого.Таким образом, мы объединяем наши функциональные ветви обратно в «тестовую» ветку.Затем наша команда QA тестирует все функции (в том виде, в каком они готовы) в ветви тестирования.

Feature1 --(merge)--> Testing
Feature2 --(merge)--> Testing
Feature3 --(merge)--> Testing

Теперь вот где все становится странным ... Обратите внимание, что ветви функцийне совсем в той же иерархии, что и ветвь «тестирование».В SVN, я думаю, вы бы назвали это «безосновательным» слиянием, которое, я не думаю, поддерживает TFS ...

В тестировании QA определенная функция может не пройти тестирование, или подробнееобычно бизнес решает: «Не берите в голову, мы не хотим, чтобы Feature2 выпустила этот выпуск, мы подождем до следующего выпуска».

В какой-то момент, когда функция прошла QA и бизнес вышел из строяна нем мы объединяем наши принятые функции с Trunk (выпуск / производство).

Feature1 --(merge)--> Trunk
Feature3 --(merge)--> Trunk

Затем мы строим наш выпуск из Trunk (и помечаем его номером версии)


Так что я ищу способ заставить нечто подобное работать в TFS.Поскольку кажется, что вы можете объединиться только с предком, я мог бы настроить это следующим образом:

Trunk
 |- Testing
     |- Feature1
     |- Feature2
     |- Feature3

И объединить ветви функций в Тестирование.Однако тогда мне нужно было бы только объединить ревизии, которые произошли от Feature1 и Feature3, из Testing в Trunk, игнорируя ревизии Feature2.Похоже, что это было бы ужасно утомительным, подверженным ошибкам, проверкой каждого изменения вручную, чтобы увидеть, из какой ветви оно пришло?Вот почему в нашей схеме SVN мы бы слили нашу ветвь функций непосредственно обратно в транк.

Кажется, что наличие ветвей функций, которые должны быть реинтегрированы в общую ветку тестирования, должно быть довольно распространенным, ноЯ предполагаю, что не вижу простого способа получить наборы изменений, которые возникли в определенном листе для следующего шага слияния.

Кто-нибудь имеет какой-либо вклад?Мы, безусловно, открыты для пересмотра нашей схемы ветвления.То, что мы делали раньше, просто работало нормально в SVN.Я подозреваю, что в git это тоже не составит труда, так как вы можете фактически объединить весь объект в один коммит и просто объединить этот коммит с любой другой веткой.

Спасибо за любой ввод!


Другие примечания:

Мы используем TFS 2010. Я забыл упомянуть об этом ранее.

Другой вариант - удаление всех изменений из функциииз ветки Testing, прежде чем объединить его с Trunk.Это было бы «обратным слиянием» в SVN.Я видел, что есть команда tf.exe /rollback, но, похоже, она принимает номер набора изменений.Каждая функция может иметь несколько наборов изменений, поэтому я все еще не вижу способа выяснить список наборов изменений в тестировании, которые возникли в результате слияния с FeatureX ...

Ответы [ 3 ]

3 голосов
/ 06 октября 2011

Необоснованные слияния поддерживаются в TFS, они должны быть сделаны через командную строку. См. здесь для ознакомления с тем, как это работает. После того, как вы произвели безосновательное слияние, устанавливается дополнительная «связь» между ветвями, и с этого момента вы сможете слиться из GUI.

Итак, предложенная вами структура может работать:

Trunk
 |- Testing
     |- Feature1
     |- Feature2
     |- Feature3

при условии, что вы произвели три безосновательных слияния (Feature1 -> Магистраль), (Feature2 -> Магистраль) & (Feature3 -> Магистраль).

Другой похожий подход, возможно, немного лучше, может быть следующим:

Trunk
 |- Feature1
 |- Feature2
 |- Feature3
     |- Testing

, а затем - путем ручной установки через необоснованные слияния (Feature1 -> Testing) & (Feature2 -> Testing).
Таким образом, вы сможете использовать Testing в качестве дамп-зоны, и как только все подтвердится для FeatureX в Testing (тесты в порядке, mgmnt решит использовать его), вы сможете нажать это к твоему сундуку.

В общем, необоснованное объединение не считается «наилучшей практикой» для руководства по ALM 1019 * по ветвлению TFS. Глядя на ваш рабочий процесс, я боюсь, что не могу найти для вас альтернативу банкомату, которая его не использует.

2 голосов
/ 06 октября 2011

Определенно есть компромиссы между обоими, и, на мой взгляд, все сводится к тому, насколько сильно дублируют ваши игровые команды друг с другом. Как отметил Пантелиф, вы действительно можете выполнять необоснованные слияния и в TFS, но это менее эффектно, чем когда у вас есть правильные отношения слияния между ветвями, и вы теряете много возможностей слияния, когда выполняете безосновательное слияние.

Я думаю, идентифицируя наборы изменений для объединения на вашей второй иллюстрации:

Trunk
  |- Testing
      |- Feature1
      |- Feature2
      |- Feature3

менее утомительно, чем вы думаете. Учтите, что при объединении нескольких наборов изменений (скажем, 1, 2 и 3) из компонента 1 в тестирование это объединение будет зафиксировано как один набор изменений в ветви тестирования (скажем, набор изменений 4). Когда вы завершили работу над функцией, вы можете объединиться в Trunk, просто объединившись с выбранными наборами изменений и выбрав набор изменений 4. (То есть вам не нужно повторно выбирать все эти исходные наборы изменений 1, 2 и 3). Конечно, вам придется проделать небольшую работу, чтобы определить, какой набор изменений слияния содержит эту функцию, но я предполагаю, что вы не объединяетесь в транк настолько часто, что его будет трудно идентифицировать. (И если это плохое предположение, тогда игнорируйте меня.)

Но большая проблема с этой структурой заключается в том, что необходимо объединить работу между Функцией 1 и Функцией 2. Допустим, они оба вносят изменения в одни и те же классы. Теперь, если вы хотите продвинуть только одну из ветвей функции до Trunk, вам придется объединить эти изменения до тех пор, пока работа другой функции не будет готова для продвижения. И это звучит скучно и подвержено ошибкам.

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

0 голосов
/ 08 октября 2011

Так что я думаю, что как справедливо упомянуто выше, необоснованное слияние из командной строки поможет вам.Во-вторых, вы упомянули около 80 коммитов.В нашем проекте мы создаем задачи в TFS.В соответствии с процессом каждый разработчик может совершить коммит, только если он сначала «связывает» свою регистрацию с задачей.Поэтому, если у меня есть исправление x, я создаю для него задачу, а затем, даже если существует 80 коммитов, все они связаны с этой задачей, что позволяет мне легко просматривать группировку в любое время в будущем.

...