Стратегия выделения ветви

Question

Наше приложение - это приложение, основанное на правилах, которое использует Drools. Он имеет основную логику структуры, а бизнес-логика, ориентированная на клиента, будет внедрена в качестве правил.

Особый выпуск содержит несколько функций. Например, Feature_Branch_Toyota_1.0, Feature_Branch_Honda_1.0 и т. Д., Будет проходить в том же выпуске Rel_1.0 и его прохождения тестирования QA. В последнюю минуту Business не нашел времени, чтобы сделать UAT (User Acceptance Testing) для Feature_Branch_Honda_1.0 изменений из-за ограничения времени или сложности изменений.

Теперь бизнес хотел бы отложить Feature_Branch_Honda_1.0 изменения в следующем месяце выпуска, но все еще Feature_Branch_Toyota_1.0 изменения должны идти в качестве запланированного в Rel_1.0.

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

Предложения/рекомендации были бы высоко оценены.

Answer 1

Казалось бы, QA полностью в ихправе попросить регрессионное тестирование.

Оригинал: Honda 1,0 + Toyota 1,0 ==> Rel 1.0 сейчас: Toyota 1.0 ==> Rel 1,0

QA теперь необходимо убедиться, что Toyota 1,0 не имеет ничего, что inadvertely зависит от Honda 1.0, казалось бы возможно что некоторые более плотные, чем ожидалось, связи приводят к некоторым взаимозависимостям. Так что определенно нужно что-то тестировать. И после того, как Honda 1.0 выйдет, Toyota 1.1 выпущена, и им также нужно будет провести регрессионное тестирование.

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

С точки зрения контроля версий я рекомендую разделенные хранилища для каждого модуля, чтобы каждый из них мог разветвляться/тег/etc. в независимых точках любого другого модуля. Именно тогда ваша матрица совместимости объединяет все это.