dchuiko
commented
5 years ago Предлагаю немного обсудить release management. Как кто планирует и управляет задачами на несколько релизов вперед?
Вопрос идет от проблемы наличия только одной ветки (develop), олицетворяющей следующий релиз. В какой-то момент, после принятия Pull Request-а, туда могут неожиданно попасть непротестированные изменения, которые могут заблокировать выкатку релиза. Ведь процесс code review, после которого Pull Request мерджится, идет параллельно с активностью тестирования. И может получиться, что разработчик смерджил заапрувленный PR, а это неожиданно отбросило релиз на несколько дней, потому что надо все перетестировать.
Можно пойти другим путем и заранее распределять задачи по будущем релизам. Для каждого релиза создается бранч и после принятия кода PR он попадет в нужный. Таким образом задача, запланированная на "через неделю" не прилетит в бранч, который выкатывается сегодня. Те заранее в issue tracker создаем версий на будущее: 1.0, 1.1, 1.2 итд, раскидываем задачи по ним и делаем аналогичные бранчи в git-е.
Можно пойти путем только feature branch-ей, без релизных бранчей, но только возникает проблема интеграции нескольких фич. Все-таки часто хочется выкатывать сразу несколько. Но перед этим их вместе надо где-то протестировать и решить конфликты. Те в какой-то момент мы выбираем несколько готовых фич, делаем бранч под релиз, сливаем все вместе и начинаем тестировать.
Глобально хочется, чтобы принятие PR-ов не замыкалось на релиз менеджере, который должен оценить: а можно ли влить эту фичу сейчас в будущий релиз или нет. Сам работаю по модели номер два и скорее доволен ей. Хочется узнать: кто как работает?!
asm0dey
viartemev
php-coder
тракпады против мышек и трэкболов