Comments 8
У нас как-то проще настроено. Для каждой задачи ветка. Задачи в основном достаточно короткие - до недели. Для веток создаются merge request. Для всех коммитов в ветки, для которых уже создан merge request, запускается сборка через GitLab CI/CD. При слиянии ветки в master запускается сборка + деплой на тестовый стенд. На тестовом стенде можно проверить функциональность. Не возникает потребности тестировать отдельные ветки.
Получается, на тестовый стенд попадает то, что уже слито в master, и нет возможности посмотреть на стенде фичу, которая ещё в ветке
Да, но если тестировать ветку, то не факт что после мержа всё будет хорошо. Поэтому мы тестируем master. Плюс это проще. При этом ничего страшного, если в master попадет что-то не то, не обязательно считать именно последний коммит релизным. Если нужно протестировать именно ветку, то человек может просто локально собрать и запустить проект.
А по тегам разворачивать пробовали?
Соотносите каждый стенд с тегом определённого формата. Например, тег формата stage-* запускает разворачивание на стейдж-стенде с коммита, на который этот тег был повешен.
А почему бы не нанять фриланс-девопса, чтобы он под вас написал код?
Что безопасность? Заключить те же соглашения что и со штатным сотрудником нельзя?
Gitlab CI — использование label для управления пайплайнами в небольших командах