Как я могу разветвить свой код таким образом, чтобы сделать возможным тестирование, не загрязняя базовую версию?

Используя TFS, мы имеем следующее:

  • Основная базовая линия
  • Ветвь разработки для каждой попытки разработки. Они объединяются обратно к базовой линии.
  • Ветка релиза, которая создается с каждым релизом. Исправления ошибок вносятся здесь, выпускаются и объединяются с исходным состоянием.
  • Используя полочные наборы, мы можем при необходимости делиться кодом между ветвями разработки, не загрязняя базовый уровень. Полезно для проверки кода.
  • Когда мы доставляем наши изменения разработки к базовому уровню, у нас есть автоматическая сборка, которая запускается и автоматически размещает наши изменения на тестовом сервере.

Проблема в том, что бизнес-аналитики не могут видеть наши изменения, пока они не будут на тестовом сервере, и в настоящее время единственный способ получить наши изменения на тестовом сервере — это проверить их на базовом уровне. Так что, если БА обнаружат что-то не так, код, к сожалению, уже находится в базовой версии, и нам придется приложить усилия, чтобы вернуть его обратно.

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


tfs branching-and-merging branching-strategy
person adam0101    schedule 22.03.2011    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

В моей компании изменения не регистрируются в базовом плане до тех пор, пока они не будут повышены и запущены в рабочей среде. Релизные ветки — это то, что развертывается на тестовых серверах... если будут обнаружены ошибки или БА захотят что-то изменить, нам не нужно мучиться с удалением изменений из базовой версии.

Однако, если у вас много одновременных выпусков, это может стать проблемой для объединения всех выпусков вместе, прежде чем перемещать их в рабочую среду, поскольку вы не выполняете слияние с базовым планом до более поздних этапов процесса. В моей компании у нас очень строгий график релизов, и мы стараемся выпускать только один релиз за раз. Из-за этого ожидание слияния релиза с базовой версией до тех пор, пока релиз не будет запущен в производство, пока не создало для нас никаких проблем или дополнительной работы...

Как часто вы делаете релизы? Сможете ли вы развернуть выпускные ветки на своих тестовых серверах и получить базовый план, представляющий то, что в настоящее время развернуто в рабочей среде?

(Я бы сделал это комментарием, но я все еще работаю над тем, чтобы заработать эту привилегию...)

person Michael Fredrickson    schedule 22.03.2011
comment
@mfredrickson Это было бы немного длинно для поля для комментариев, и я в любом случае думаю, что это разумный ответ. - person Andrew; 22.03.2011
comment
Мы используем SCRUM и выпускаем в конце каждого спринта, который обычно длится около 3-4 недель. Итак, вы создаете ветку релиза для следующего релиза, затем создаете из нее ветки разработки, затем объединяете ветки разработки обратно в релиз и объединяете релиз с базовым планом после релиза? - person adam0101; 23.03.2011
comment
О, и если вы еще не можете комментировать, просто отредактируйте свой ответ и добавьте продолжение внизу. - person adam0101; 23.03.2011
comment
@adam0101 Вот как мы это делаем ... но в данный момент для нас это постоянно развивающийся процесс. Прямо сейчас самое неприятное для нас — запустить еще один релиз до того, как предыдущий релиз будет запущен в производство. В этом случае мы либо запускаем новый выпуск, ответвляясь от ожидающего выпуска, либо отделяясь от базовой версии, а затем объединяя продвигаемую версию с новой версией в то же время, когда она объединяется с базовой версией. Для нас это зависит от размера релиза... если это тонна изменений, мы отделяемся от предстоящего релиза, чтобы избежать огромного слияния позже. - person Michael Fredrickson; 23.03.2011
comment
Поэтому, используя эту стратегию, мне пришлось бы объединить и проверить свои изменения в ветке выпуска, что запустит автоматическую сборку, которая помещает изменения на тестовый сервер. Что произойдет, если БА не одобрят мои изменения? Теперь у меня есть свои изменения, смешанные с изменениями, которые должны выйти в ветке релиза. Я все еще пытаюсь понять, как другие справляются с этим. - person adam0101; 23.03.2011
comment
Ключ дублирует базовые сборки на любой ветке, в которой вы ведете активную разработку, чтобы развернуть ее где-нибудь, что вы можете проверить. Тяните от базовой линии часто и прямо перед тем, как оттолкнуться назад. Это поможет разрешить начало второй активной ветки разработки. - person Ryan Cromwell; 24.03.2011

arrow_upward
1
arrow_downward

Я бы не предпочел этот подход, я бы предложил:

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

Ветка Release, которая создается из Main для каждого выпуска. Эта ветвь будет использоваться для создания сборок выпуска и будет развернута в тестовой среде.

Ветвь разработки, созданная из ветки релиза, будет использоваться для разработки и будет объединена с релизом, когда я буду готов предоставить свою сборку для тестирования.

person Jehan33    schedule 22.03.2011
comment
Если ваши изменения не проходят тест, как вы справляетесь с тем, что ваши неработающие изменения смешиваются с другими изменениями в ветке релиза? Вы как-то откатываете свои изменения? - person adam0101; 23.03.2011
comment
Если изменения не проходят тестирование, если требуется исправление, то оно должно быть исправлено в ветке разработки и объединено с релизом. Если нам вообще не нужны эти изменения, они будут отброшены с помощью labels или команды tf rollback. - person Jehan33; 23.03.2011
comment
Если бы другие разработчики зафиксировали изменения в файле ПОСЛЕ того, как вы и ваши изменения должны были быть отброшены, разве вам не пришлось бы каким-то образом разъединять файлы, чтобы удалить ваши изменения, а затем повторно объединять изменения других разработчиков? Как бы вы справились с этим? - person adam0101; 24.03.2011
comment
Разработчик не будет выполнять никаких проверок, проверка в Release Branch, продвижение кода здесь происходит ведущим разработчиком. В процессе разработки, если было отменено изменение для вышеуказанного сценария, разработчик получает конкретную версию файлов для той версии, которую он хочет откатить, и выполняет проверку. - person Jehan33; 24.03.2011