в Docker-е, со схемой где создаются релизные ветки, develop ветка при мердже автоматом собирается и деплоится на DEV окружение, ветка release-xxx на QA окружение, и после всех тестов и проверок без пересборки на прод(ну или с пересборкой на qa окружение)
Хочется уйти от релизных веток на использование git tag.
Насколько это правильный такой подход? И как поступать с тегами, которые не прошли проверку на QA окружение? Переназначить тэг другому коммиту или же инкрементить тэг?
стор отдельно можно установить
вариант с тэгами вполне себе оправдан. На одном из проектов мы так и жили с семантик-плагином, который сам версии проставлял и не создавали при этом отдельных бранчей под релизы. Тут вопрос стратегии бранчевания скорее. переносить тэги в таком варианте - плохая идея, это ломает историю. Логичнее новую версию выпускать и все - это ж не обязательное требование чтобы каждый "внутренний" релиз становился публично доступным
Истории как таковой еще нет, проект в самом начале пути своего. Вот это хочется выбрать правильный путь
а единственного правильного пути нет. Есть как обычно масса моментов, которые могут вносить что-то свое. Плюс со врменем обстановка может смениться и соответсвенно придется вносить изменения в этот процесс
Окей, тогда последний вопрос. Как вы поступаете с git tag в ситуации, когда был собран образ, выложен на QA(STG/Pre-Prod) и не прошел финальное тестирование. Следующий образ собирается с новым тэгом или же вы переиспользуется старый?
лучше тэг ставить уже после тестирования по идее
да, новый тэг соответсвующий новой версии
Мы юзаем для этого CiCD в гитлабе там очень просто, и каждый этап восполняется в своем докере. Для построения самих докеров юзаю kaliko
не kaliko, а kaniko
Обсуждают сегодня