Проблема контроля версий при развертывании версий

Question

мы обсуждаем, как развернуть в рабочих ревизиях с закрытым UAT без ревизий со статусом не закрытого UAT.

Мы используем SVN, и мы выяснили, что мы не можем просто принять исправления без предварительных пересмотров того же файла.

Позвольте мне объяснить это на этом примере: у нас есть 3 изменения, сделанные в одном файле:

r1: UAT закрыт (готов к развертыванию) r2: UAT не закрыт (не готов) r3: UAT закрыт (готов к развертыванию)

теперь я хочу развернуть только те изменения, для которых UAT закрыт (например, r1 и r3). В SVN это невозможно, поскольку r3 содержит также изменения r2.

Как ты заставил это работать? Может ветвление? Или просто возьмите r1 и подождите, пока r2 не закроет UAT?

спасибо

Answer 1

Исходя из того, что вы говорите, я бы предложил ветвление для каждой проблемы UAT, а затем объединить их обратно в магистраль, когда UAT закрыта.

Таким образом, вы бы получили:

Main Branch
 - Branch R1
 - Branch R2
 - Branch R3

Все ветви 1, 2 и 3 начинаются в одно и то же время, но R1 и R3 закрыты UAT до R2, и принимается решение начать работу с тем, что у вас есть.

Таким образом, вы можете объединить R1 и R3 в Main, но оставить R2 там, где он есть.

Если бы вы пошли с этим процессом, я бы также предложил:

Main Branch
- Staging Branch
- - Branch R1
- - Branch R2
- - Branch R3

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

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

Answer 2

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

Итак, создайте ветку релиза, и вы можете поместить туда все свои изменения UAT. Вы можете перейти от R1, а затем объединить изменения в R3 или перейти от R3 и вернуть изменение R2 с помощью svn merge (См. Отмена изменений в руководстве Subversion on line).

Теперь вы можете добавлять и вычитать изменения, относящиеся к выпуску, не влияя на текущий проект. Если R2 получит одобрение на выпуск позднее, его можно объединить обратно в ветку выпуска.

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