Как правильно вести репозиторий в CD/CI?
Подскажите какие лучшие практики?
Вот у нас есть master ветка. То что там = продакшен. Как что-то попадает в мастер ветку, система это чувствует и автоматически деплоит. Есть вторая ветка "dev". То что там = тестовый staging сервер. Как что-то попадает в "dev" ветку, система это чувствует и автоматически деплоит на тестовый сервер И прогоняет юнит тесты и e2e тесты.
Ну и вот вопрос, когда членам команды пооступает какой то таск, например "Напиши в шапке сайта "С новым годом'", откуда они должны форкаться? От master ветки, где все стабильно и 100% запустится у них на локалке, или от dev ветки, где все возможно не стабильно и тесты не прошли и сайт вообще не запускается, и тогда наш сотрудник не сможет приступить к изменению текста в шапке сайта, ведь сайт у него на локалке вообще не поднимится.
Но с другой стороны если он форкается от мастер ветки, то у него не будет текущей уже проделанной работы другими членами команды, конфликты своего кода и этой команды он должен решать. Он же ведь не увидет их код, как тогда решать конфликты?
Ответы (1 шт):
Это уже как вы внутри команды довогоритесь. Нужно договориться, как вы скидываете различные типы изменений, исходя из важности/критичности вашего продукта (т.е. сколько вам будет стоить, если сайт упадет):
- Плановые доработки через дев ветвь. Там проходячит все тесты и все такое.
- Заплатки, которые не требуют тестирования (из разряда: поменять размер шрифта или текст на форме). Ответвились от мейн, поменяли шрифт и пул-реквест обратно.
- Заплатки, которые требуют тестирования. Решаете когда должа она пойти:
- Срочная - ветвь от мастера + прикручиваете тесты.
- Клиент может подожать - включаете через план и ведете через дев ветвь.
Нормальная практика - создать hotfix ветвь после релиза и нацелить на нее тесты. Все срочные исправления через нее. Хотфиксы желательно и в дев ветвь передавать, чтоб команда в ней решала конфликты, а не при релизе в мастер.