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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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