Управление релизами с распределенной системой контроля версий - PullRequest
3 голосов
/ 15 мая 2010

Мы рассматриваем возможность перехода с SVN на распределенную VCS на моем рабочем месте.

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

  • Узнайте, какие изменения доступны для слияния.
  • Запустите запрос, чтобы найти дефекты / заявки, связанные с этими изменениями.
  • Отфильтровать изменения, связанные с «открытыми» билетами. В нашей среде заявки должны находиться в закрытом состоянии, чтобы объединиться с веткой выпуска.
  • Отфильтруйте изменения, которые нам не нужны, в ветке релиза. Мы очень консервативны, когда дело доходит до слияния изменений. Если изменение не является абсолютно необходимым, оно не объединяется.
  • Слияние доступных изменений, предпочтительно в хронологическом порядке. Мы группируем изменения вместе, если они связаны с одним и тем же билетом.
  • Заблокируйте нежелательные изменения в ветке релиза (svnmerge block), чтобы нам больше не приходилось с ними сталкиваться.

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

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

Например, сбор вишни кажется запоздалой мыслью в ртути. (Вы должны использовать расширение «трансплантат», которое по умолчанию отключено). После того, как вы выбрали вариант ветки, он все еще отображается как доступная интеграция. Сбор вишни нарушает ртутный способ работы.

Похоже, DVCS лучше подходит для ветвей функций. Нет необходимости выбирать вишню, если вы сливаетесь непосредственно из ветви функций в транк и ветку релиза. Но кто хочет делать все это слияние все время? И как вы запрашиваете, что доступно для слияния? И как вы убедитесь, что все изменения в ветви функций принадлежат друг другу? Звучит как полный хаос.

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

1 Ответ

2 голосов
/ 15 мая 2010

Вы действительно хотите использовать git в этой ситуации, потому что он намного превосходит управление слиянием и выпуском. Git допускает процесс подписания изменений для выпуска; фактически он обеспечивает поддержку нескольких уровней управления выпусками именно потому, что именно так управляется Linux.

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

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

...