АХ
Size: a a a
2020 April 23
АХ
подскажите пожалуйста как можно сделать так?
TF
но ведь секьюрно ;)
S
но ведь секьюрно ;)
это последнее, на что обращаешь внимание, особенно когда посмотришь в скрипт venv_init.sh
AT
A
Да
AT
Да
и сколько у вас уже тегов?
A
и сколько у вас уже тегов?
Да хз, а это важно?
AT
имхо это не удобно тегать каждый билд
AT
я и не тегаю, о один сотрудник предлагает такой вариант, вот я и хочу узнать как у других? чем лучше это просто поиск по коммитам в ветке release-candidate для удобства тестировщикам а сам release уже тегом финальный и единственный билд?
DV
я и не тегаю, о один сотрудник предлагает такой вариант, вот я и хочу узнать как у других? чем лучше это просто поиск по коммитам в ветке release-candidate для удобства тестировщикам а сам release уже тегом финальный и единственный билд?
А чего вы таким макаром собираете? У нас приложуха на электроне, тегаем каждый билд по семверу пререлизными тегами с той лишь разницей, что не на каждый мр, а, например, раз в день. Когда решаем, что к релизу готово - бампаем минор или мажор. Когда надо хотфикс выпустить - бампаем патч. Например
DV
Тестеры всегда знают, что тестят, в жире тикеты прикрепляются к релизам. Тикет прикреплен - значит в сборку попал
DV
Соответсвенно, ПМ когда мержит, прикрепляет тикет к релизу, но говорят, что это можно автоматизировать 😅
AT
Тестеры всегда знают, что тестят, в жире тикеты прикрепляются к релизам. Тикет прикреплен - значит в сборку попал
ну у нас гора сервисов на всем что можно, ну вот я думаю что сначала делать ветки release candidate и давать тестировщикам последний коммит с этой ветки и в jira баги привязывать к MR, когда тестировщики говорят что всё ок, то уже увеличиваем мажор или минор версию, просто вот коллега предлагает для удобства тегать каждый пайплайн для лучшего поиска версии.. моё мнение что лишняя мера
DV
Без совета профессионального сообщества =)