Мы рассматриваем возможность перехода с 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 ...