2022-02-03 09:00:29
Уж0сы gitFlow
TL;DR примечание для продактов
Ниже приводятся аргументы «за» и «против» разных способов управления исходным кодом ПО, в частности идет хейт на широко распространившийся подход #GitFlow (GF).
Тезис: если у вас такой подход (можно узнать у лида), то можете забыть о нормальной скорости поставки.
Следствие: если кажется, что скорость поставки высокая, то возникает вопрос: «а ты точно продакт?»
Ниже текст для тех, кому хочется похоливарить предметно
Про православный trunk-based уже писал (бодрый доклад и правильная шутка про ветвление), а тут дошли руки до критики распространённого GF.
Но одно дело говорю я — меня и разработчиком-то назвать нельзя: так рядом с монитором стоял, — а другое дело умудренные седеной старцы вещают.
Эпитет:
Как нам говорит дедушка Craig Larman, continuous integration (CI) — это интегрировать постоянно, а не использование всяческих инструментов.
Когда мы в 2017 решали какую модель управления кодом будем делать, помню, что не смотря на всю ортодокласальность, никто не выбрал GitFlow, ибо это ж сколько надо быть дофига умным, чтобы во всем этом разобраться и, главное, потом поддерживать, да еще на 3 команды! Dave Farley в своем видео, утверждает что GitFlow несовместим с CI и вот почему
Используемые 5 видов веток (master, dev, hot fix, release, feature-branches) нужны только для того, чтобы скрыть изменения от членов команды, работающих над одним продуктом, друг от друга, в то время как единая ветка master — максимально оголяет эти изменения
Действительно, CI - это ситуация, при которой у всех участников процесса разработки в моменте (как минимум несколько раз в день) всегда последняя работоспособная версия системы, над которой они работают.
Когда в команде есть CI, то разрабочики не пытаются угадать, будут ли разработанные ими части работать вместе — они проверяют это часто… постоянно
(continuously)Где в GF содержится «золотая ветка»?
Не в dev, так как могут забыть в нее что-то слить из hotfix или release.
А если не забывают, то зачем нужна master?
Чтобы понимать, что в production? То есть в dev могут быть изменения, которых нет в master?
Если такой ситуации нет, то опять возникает вопрос, зачем 2 ветки и достаточно иметь только master?
Используемая схема ветвления снижает скорость получения обратной связи
Допустим, «золотая ветка» у команды в master.
К сожалению, в подходе GF слияние веток из релизной ветки или из хотфикса делается только после того, как разработчик уверен, что у него все работает. Получается, что разработчик получает ОС на работу только после того, как все заработало. Намного круче, когда любой разработчик понимает, что его изменение можно вливать в основной код и, что еще более важно, понимает до вливания, что делать это небезопасно!
То есть узнать нужно сейчас, а не через дни , недели, месяцы работы в стол, иначе ОС будет несвоервеменной
Основной критерий безопасности — релиз!
Поэтому надо увеличить поставку в master, а это как бы опять CI.
Итак, критика понятно, а что делать?
Dave предлагает работать в локальной версии master, делать частые кометы в него же, а когда все ок (пройдены тесты изменений) , запускать слияние в репозиторий, где уже начнет отрабатывать Pipeline(сборка, прогон тестов и про)
Что делать, если тестов нет?
Короткий ответ: you’e fucked!
Длинный: можно оставаться в таком состоянии и просто закупиться вазелином и краской от седых волос, а можно сделать, как в одной моей команде, у которой помимо бизнесовой цели спринта была и техническая: «test coverage +1%»
CI фундаментально является более инкрементальным подходом к разработке софта
Эпилог
1 CI\CD используется не только «для сайтиков». Но и в таких компаниях как Tesla, Ericson, Siemens.
2 Vincent Driessen придумал GitFlow в 2010году, когда вышла книга по continuous delivery (CD) вышла у Dave.
Поэтому Винсент не знал о том, как чего у нормальных парней делается, поэтому и навертел не понятного.h
277 viewsSergey Artyuhov, edited 06:00
2
