Комбинированные ветви обслуживания и выпуска
Я думаю, что у вас такие же требования, как и у наших людей. КИ поможет вам автоматизировать, но не решит основную организационную проблему.
Итак, у вас есть 2 типа чеков:
- обычный несрочный код (планируется выпускать время от времени)
- код срочного «исправления» (происходит после выпуска, если что-то проскальзывает без достаточного тестирования или когда клиент Х звонит, потому что он хотел, чтобы кнопка розового цвета не была фиолетовой, и он угрожает расторгнуть контракт: P)
Оба случая различны, и вы должны разделить их. Я думаю, ваш подход уже близок к ответу, но вы делаете «слишком много» * 1015 *
Позвольте мне описать вам, что мы делаем:
Структура репозитория
trunk (is our project with components and all)
branches
|
-- 1.0-stable-week-40
|
-- 2.0-stable-week-42
|
-- 3.0-stable-week-44
tags
|
-- 1.0.0
|
-- 1.0.1
|
-- 1.0.2
|
-- 2.0.0
|
-- 2.0.1
|
-- 3.0.0
Как видите, у нас есть магистраль для всех основных разработок. Мы также создаем стабильные ветки для подготовки и тестирования релизов каждые 2 недели и помечаем все релизы по мере их появления.
Жизненный цикл выпуска (обобщенно)
После новой версии мы поддерживаем ветвь (например, 1.0) до выхода следующей основной версии.
Наша политика заключается в том, что в это время в эту ветку могут быть включены ТОЛЬКО критические исправления. Они проходят только минимальное тестирование и могут быть выпущены в считанные минуты, создав новый тег из нашей ветки обслуживания.
В середине периода обслуживания (1 неделя после выпуска) мы создаем новую ветку из нашего ствола под названием "2.0". Все не так срочно, разработка уже в багажнике будет в этом выпуске автоматически. Другие вещи могут быть добавлены «осторожно», например срочные исправления, которые поступают из текущей активной ветки обслуживания (объединение от 1.0 до 2.0 в транк).
После того, как прошла еще одна неделя и все тестирование было завершено, ветвь 2.0 помечается как 2.0.0 и выпускается, если не возникало серьезных проблем. Ветвь обслуживания 1.0 будет удалена и удалена.
Таким образом, мы можем отделить срочные от несрочных изменений и получить относительно безболезненные и стабильные релизы.
То, что вы делаете, в значительной степени то же самое, но вы переходите от тега, который, когда вы закончите, снова тегирует. Это немного много :).
Ответвление от тегов - это тоже плохой стиль. ветка из веток.
политики филиалов
Это помогает команде, если вы записываете политику для каждого из ваших типов филиалов, позволяя им делать больше самостоятельно, без того, чтобы парень-релизчик постоянно сидел у них на шее и заманивал их коммитами;)
Наши правила можно описать так:
Слияние становится менее тренировкой ума, когда вы пытаетесь слиться только в одно «направление». (Вы могли бы хотеть Google для масштаба тофу, но это становится немного ОТ теперь).
Следите за тем, чтобы слияния выполнялись разработчиками постоянно, а не менеджерами релизов, чтобы ограничить узкое место.
В то время как один выпуск является активным и активно поддерживается получение исправлений, мы уже начинаем готовить следующий, изолируя его от возможных нестабильных изменений в стволе и давая время «созревать».
У вас могут быть разные требования к продолжительности инкубации кода и тестирования или продолжительности итерации выпуска, конечно. Адаптировать:)