3

Подскажите какие лучшие практики?

Вот у нас есть master ветка. То что там = продакшен. Как что-то попадает в мастер ветку, система это чувствует и автоматически деплоит. Есть вторая ветка "dev". То что там = тестовый staging сервер. Как что-то попадает в "dev" ветку, система это чувствует и автоматически деплоит на тестовый сервер И прогоняет юнит тесты и e2e тесты.

Ну и вот вопрос, когда членам команды пооступает какой то таск, например "Напиши в шапке сайта "С новым годом'", откуда они должны форкаться? От master ветки, где все стабильно и 100% запустится у них на локалке, или от dev ветки, где все возможно не стабильно и тесты не прошли и сайт вообще не запускается, и тогда наш сотрудник не сможет приступить к изменению текста в шапке сайта, ведь сайт у него на локалке вообще не поднимится.

Но с другой стороны если он форкается от мастер ветки, то у него не будет текущей уже проделанной работы другими членами команды, конфликты своего кода и этой команды он должен решать. Он же ведь не увидет их код, как тогда решать конфликты?

Иван Вольнов
  • 119
  • 1
  • 7
  • 1
    Думаю это Вам поможет https://habr.com/ru/post/106912/ – Николай Гнап Jan 11 '21 at 06:05
  • 2

    или от dev ветки, где все возможно не стабильно и тесты не прошли и сайт вообще не запускается < - тогда у Вас проблема посерьезней. В таком случае обычно нужно все бросить и начать лечить ветку, что бы она была рабочей. Если это обычное состояние этой ветки - это проблема команды. И как только это будет решено, сама проблема, поставленная в вопросе, исчезнет.

     – KoVadim Jan 11 '21 at 09:32
  • не силён в CI-CD, но выскажусь. Мне кажется разумнее тестить тематическую ветку фичи\фикса перед тем как сливать её в общую. Ну и при таком раскладе может быть одной общей достаточно будет. – 4per Jan 11 '21 at 14:18
  • "Мне кажется разумнее тестить тематическую ветку фичи\фикса перед тем как сливать её в общую" это теряет смысл всего CD/CI так как ты не можешь локально протестить, ведь смысл интеграционного тестирования это интеграция твоего кода с кодом других коллег и поимка поломок вызванных этой интеграцией. – Иван Вольнов Jan 11 '21 at 16:05
  • хз поможет или нет, вот тут есть немного мыслей - раз, два – tym32167 May 04 '21 at 16:45

1 Answers1

2

Это уже как вы внутри команды довогоритесь. Нужно договориться, как вы скидываете различные типы изменений, исходя из важности/критичности вашего продукта (т.е. сколько вам будет стоить, если сайт упадет):

  1. Плановые доработки через дев ветвь. Там проходячит все тесты и все такое.
  2. Заплатки, которые не требуют тестирования (из разряда: поменять размер шрифта или текст на форме). Ответвились от мейн, поменяли шрифт и пул-реквест обратно.
  3. Заплатки, которые требуют тестирования. Решаете когда должа она пойти:
    • Срочная - ветвь от мастера + прикручиваете тесты.
    • Клиент может подожать - включаете через план и ведете через дев ветвь.

Нормальная практика - создать hotfix ветвь после релиза и нацелить на нее тесты. Все срочные исправления через нее. Хотфиксы желательно и в дев ветвь передавать, чтоб команда в ней решала конфликты, а не при релизе в мастер.

  • "Заплатки, которые не требуют тестирования" -- Не, у нас такого не бывает, любой фикс или фитча обязана иметь хотя бы один тест =) но мысль вашу понял, спасибо – Иван Вольнов Jan 11 '21 at 16:07
  • "Нормальная практика - создать hotfix ветвь после релиза" а разве если после релииза в продакшене обнаружен ХОТЬ ОДИН баг, это не ЧП и не повод откатываться до предыдущей версии? =) – Иван Вольнов Jan 11 '21 at 16:08
  • @user403405 если обнаружен баг - это не чп. Откат или нет - это копромис, где из нас крови выпьют меньше: пока мы исправляем баг (т.е. баг маленький, он не влияет на функционал и народ потерпит) или пока откатываемся (система упала, не работает важный или часто используемый функционал). Если откат простой - это хорошо (вернулись и все), а если много компонентов откатывать - тут нужно принимать взвешенное решение. Да и ведь иногда присутствует раздел в релиз-ноутс: Известные проблемы... –  Jan 11 '21 at 16:28
  • хм, ну мы обычно делаем систему двустороннюю миграций и любую миграцию можно откатить назад), но в целом да, вы правы – Иван Вольнов Jan 11 '21 at 17:06