Как из Jira рулить что попадет в релиз?

Question

[AstonMartin]

Добрый день!

Маленькая команда. Разрабатываем php приложения для внутренних нужд. Репозиторий в битбакете в облаке. Там же в Jira в kanban-е рулим задачами. Используются smart commits для связывания задач и коммитов.
В битбакете только одна master ветка.
Есть тестовый сервер, туда автоматически все деплоится после каждого пуша в репозиторий. Есть прод сервер, куда код выкладывается ручным git clone тоже с мастер ветки после некоторого тестирования. Вообщем, все примитивно и довольно эффективно для нашей микро команды).
Про git flow знаю, но считаю, что полноценный флоу сейчас для нас не нужен.

Возникла такая проблема: например реализовали 10 фич, тестируем, 2 из них требуют довольно длительной доработки. Но ждать не хочется, а хочется готовые 8 залить на продакшн. Соответственно, скорее всего нужна dev ветка, а в мастер из нее должны попадать уже протестированные фичи.
Собственно вопрос: как максимально просто реализовать процесс мерджа протестированных фич из дева в мастер? В идеале чтобы это делалось прямо из Jira ;) Например, перетащил задачу из статуса Review в Done и Jira сама сделала merge dev -> master для всех коммитов, вошедших в задачу. Может в jira есть какой-то плагин для этого?

Answer 1

[index0h]

Про git flow знаю, но считаю, что полноценный флоу сейчас для нас не нужен.

как максимально просто реализовать процесс мерджа протестированных фич из дева в мастер?

Вы себе противоречите

В идеале чтобы это делалось прямо из Jira

Конфликты тоже jira править будет?))

По моему вы пытаетесь автоматизировать то, что вам ненужно. Это конечно же хорошо может выглядеть, но опять же, какой в этом смысл? Ну сэкономите вы 5 минут, что с того?

А вот на счет флоу с ветками я бы на вашем месте по раньше разобрался.

как максимально просто реализовать процесс мерджа протестированных фич из дева в мастер?

1. На тестовом сервере резетимся до origin/develop
2. Накатываем ветку с фичей
3. Тестируем
4. Убирам за собой тестовом сервере и опять резетимся до origin/develop
5. Если все ок - ТЛ мерджит фичу в develop

Шаги 1, 2, 4, 5 в сумме занимают минут 5.

Comments

[AstonMartin]

Спасибо за ответ!

Конфликты будут решать сами разработчики на этапе пуша в дев.

Понятно, что самостоятельный мердж времени занимает не много, но просто не хочется делать эту бессмысленную дополнительную работу (у нас частые релизы + вероятность ошибки при ручной работе), которую, скорее всего можно автоматизировать. Jira же знает какие коммиты вошли в задачу и скорее всего там можно запустить какие-то post-скрипты после смены статуса задачи.
Если ничего не найду, то конечно придется вручную.

[index0h]

@AstonMartin

просто не хочется делать эту бессмысленную дополнительную работу

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

вероятность ошибки при ручной работе

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

Jira же знает какие коммиты вошли в задачу и скорее всего там можно запустить какие-то post-скрипты после смены статуса задачи.

Вообще говоря в этом случае вы только увеличиваете вероятность ошибки.
Не оперируйте коммитами, вместо этого - ветками. Допустим немерджено что-то по ошибке, какие ваши действия? заревертить все коммиты? Есть путь проще:
все ветки мерджатся в no fast forward режиме, далее для отмены вам достаточно заревертить коммит с мерджем ветки в develop.

[AstonMartin]

Спасибо, очень полезно.