Основной постулат TBD - не делай долгих фича-веток. А фича-тогглы лишь инструмент для достижения этой цели.
ОЧЕНЬ плохо расписан git flow.
Ну я так больше про TBD рассказываю-) даже в названии это отразил.
Для git-flow я в целом раскрыл основные свои соображения от использования именно этого подхода. Сложный. Не очень удобен для CI\CD процессов. При этом не отрицаю множества мест и сценариев, где он отлично подойдет.
Аргумент - только джуны не могут в нормальный git а остальные могут и потерпеть другие флоу.
В целом - все так. Нельзя сказать (и я не говорю) что так правильно а так не правильно.
Я освещая мой любимый подход с TBD и рассказываю о его основных отличиях от других, и как он помогает большим командам эффективно гибко и быстро разрабатывать новый функционал
Потребители данных не работаю с базой. Они работают с сервисом используя некий(пусть будет RPC) протокол.
Если сервис меняет внутренний способ хранения данных - НОУ ПРОБЛЕМ. Его задача - чтобы публичный контракт оставался обратно совместим.
Допустим - раньше бизнесово у клиента мог быть один адрес, а теперь их стало много. А потребители данных используют контракт где "много" не заложено.
А таком варианте - ты создаешь новые метод в сервисе, в контракте которого уже будет много адресов. И дальше - задача потребителей, ЕСЛИ у них есть изнес-необходимость работать с несколькими адресами - пусть переключаются на новый метод. Если-же задачи нет, и их устраивает один адрес - тоже норм.
Пример: хочу в БД хранить массив JSON'ов вместо одного JSON'а, аналогичные конструкции записывать в БД, это используют 20 потребителей через вычитку из БД.
В микросервисах обычно не позволяют кому-попало в базу лезть своими руками немытыми.
У сервиса есть контракт с его потребителем, и он должен его соблюдать. способ хранения данных - часть внутренней кухни сервиса.
Как делать хотфикс, если функционал из убежавшего вперед мастера еще не должен быть выпущен? Аналогично Git Flow?
тут есть несколько разных способов.
делать по аналогии с git-flow
идти в сторону ci\cd: фиксить мастер и катить уже его.
Второй подход больше отражает суть TBD - которая приводит нас к чистому мастеру, готовому к релизу в любой момент. И возможность быстро доставлять ценность клиенту
почему одни и те же фичи в TBD — короткоживущие, добавляющие TTM, а в gitflow — порождающие тонны конфликтов?
Далеко не все фичи это 1-3 дня разработки. Как правило времени на реализацию и тестирование тратится существенно больше. (хот-фиксы и перекрашивание кнопок не берем)
Потому - подход TBD позволяет выкатить фичу в прод под флагом. И застолбить под нее место. Обозначить интерфейсы. Другие команды будут видеть код, что под фича-флагами. Будут понимать - что разработка в этом месте ведется и будут это учитывать.
В случае-же git-flow, чем дольше фича не попадает в master будет находится тем дольше и чаще надо будет решать конфликты. Тем больше шансов что появится костыльная дублирующая реализация.
Плюс code review в gitflow легче
Тут термин "легче" штука относительная. И про это я в статье тоже писал.
Отревьювить и дать грамотный фидбек на 50 строк изменений проще и быстрее, чем при 1000 строк изменений.
Но при этом требуется держать контекст предыдущих итераций.
Мое опыт говорит, что опытный разработчик имеющий понимание фичи - достаточно легко справится с поддержанием контекста от итерации к итерации. При этом времени на ревью итерации он тратить сильно не много (итерация маленькая) Ревью будет более качественным (мы когда-то даже статистику строили - зависимость времени ревью от размера PR)
А вот для новичка держать контекст прошлой итерации очень сложно, потому - ему поще делать фичу целиком
Ну и если кратко - если ты позвонил на подменный номер, и позвонишь на него-же завтра - ты точно так-же дозвонишься до продавца. (при условии что оба звонка у тебя идут с одного и того-же телефона)
Если звонил вчера со своего телефона а сегодня перезваниваешь с телефона жены - есть риск не дозвонится.
Не успела на самом деле: к моменту выхода в php почти не осталось сложного кода что обходит много сервисов. Все растащили по сервисам
Посмотри на утилиту bfg для гита
Мы не столь давно удаляли такие артефакты. Сократили размер репы почти в 5 раз.
Чекауты стали быстрее, ci/cd ускорился.
Но сломался ci/cd, ибо он кешировал репы и комиты.
понимаю вашу боль.
Это очень частая проблема с тогглами.
И важно начинать работать над их актуализацией как можно раньше.
Мы решили проблему кардинально.
Растащили из по сервисам и в процессе освежили, убрав не актуальные.
Сейчас домен сервиса достаточно небольшой и нужды у отдельной утилите для этого нет.
Вы правы. Оптимизацией фронт-части, уменьшение TTFB и прочие метрики - это важная составляющая оптимизации.
И этим нужно заниматься (мы сейчас именно этому способу оптимизации уделяем меньше времени чем хотелось бы)
Но статья вовсе не про это. Картинки, подготовка рекомендаций - это отдельная задача, важная для того, чтобы скрол главной был гладеньким.
Статья о том, что даже решение уровня "закидаем железом" перестало быть достаточно эффективным.
Все верно. спасибо!
Основной постулат TBD - не делай долгих фича-веток. А фича-тогглы лишь инструмент для достижения этой цели.
Ну я так больше про TBD рассказываю-) даже в названии это отразил.
Для git-flow я в целом раскрыл основные свои соображения от использования именно этого подхода. Сложный. Не очень удобен для CI\CD процессов. При этом не отрицаю множества мест и сценариев, где он отлично подойдет.
Жаль ни разу не находил, было бы здорово!
Ну и тут понятно - что есть пачка трейдоф.
К примеру TBD не очень подходит под классический релизный цикл: c отгрузкой инкремента раз в пол года
Или к примеру TBD не очень удобен для опенсорс продуктов (не без исключений. лишь большая или меньшая степень удобства с подходом)
ничего не понял.
Аргумент - только джуны не могут в нормальный git а остальные могут и потерпеть другие флоу.
В целом - все так. Нельзя сказать (и я не говорю) что так правильно а так не правильно.
Я освещая мой любимый подход с TBD и рассказываю о его основных отличиях от других, и как он помогает большим командам эффективно гибко и быстро разрабатывать новый функционал
Вопрос достаточно сложный, на самом деле.
Я исхожу из предпосылок - что все сервисы имеют свои НЕ СВЯЗАННЫЕ друг с другом тогглы.
Такой подход заставляет каждый раз внутри сервиса думать - что делать если фича включена и выключена.
Так как микросервисы не большие по своей природе - тогглов там не бывает много.
Ну а дальше отталкиваемя от того - что за тоггл. Тоггл новой фичи, нужно включить в dev-середе, и прогнать цикл тестирования
Я наверное не до конца понимаю проблему.
Потребители данных не работаю с базой. Они работают с сервисом используя некий(пусть будет RPC) протокол.
Если сервис меняет внутренний способ хранения данных - НОУ ПРОБЛЕМ. Его задача - чтобы публичный контракт оставался обратно совместим.
Допустим - раньше бизнесово у клиента мог быть один адрес, а теперь их стало много. А потребители данных используют контракт где "много" не заложено.
А таком варианте - ты создаешь новые метод в сервисе, в контракте которого уже будет много адресов. И дальше - задача потребителей, ЕСЛИ у них есть изнес-необходимость работать с несколькими адресами - пусть переключаются на новый метод. Если-же задачи нет, и их устраивает один адрес - тоже норм.
Немного подушню за математику: не 200 интераций по 50 строк а 20 итераций по 50 строк.
эти итерации делаешь быстро. Учитывая современные команды и гибкие методологии разработки - это только в плюс.
Каждый выбирает фломастер на свой вкус, как говорится. Главное что красный вкуснее=)
Не было задачи показать что git flow - сакс. Но он действительно хуже подходит по современные процессы с ci\cd и гибкими методологиям.
Но при этом git flow хорошо ложится на более медленные циклы разработки, вида классической отгрузки продукта по версиям
В микросервисах обычно не позволяют кому-попало в базу лезть своими руками немытыми.
У сервиса есть контракт с его потребителем, и он должен его соблюдать. способ хранения данных - часть внутренней кухни сервиса.
тут есть несколько разных способов.
делать по аналогии с git-flow
идти в сторону ci\cd: фиксить мастер и катить уже его.
Второй подход больше отражает суть TBD - которая приводит нас к чистому мастеру, готовому к релизу в любой момент. И возможность быстро доставлять ценность клиенту
За одно это с меня пиво!
Ух. Спасибо за комент. Мне прямо нравится!
Далеко не все фичи это 1-3 дня разработки. Как правило времени на реализацию и тестирование тратится существенно больше. (хот-фиксы и перекрашивание кнопок не берем)
Потому - подход TBD позволяет выкатить фичу в прод под флагом. И застолбить под нее место. Обозначить интерфейсы. Другие команды будут видеть код, что под фича-флагами. Будут понимать - что разработка в этом месте ведется и будут это учитывать.
В случае-же git-flow, чем дольше фича не попадает в master будет находится тем дольше и чаще надо будет решать конфликты. Тем больше шансов что появится костыльная дублирующая реализация.
Тут термин "легче" штука относительная. И про это я в статье тоже писал.
Отревьювить и дать грамотный фидбек на 50 строк изменений проще и быстрее, чем при 1000 строк изменений.
Но при этом требуется держать контекст предыдущих итераций.
Мое опыт говорит, что опытный разработчик имеющий понимание фичи - достаточно легко справится с поддержанием контекста от итерации к итерации. При этом времени на ревью итерации он тратить сильно не много (итерация маленькая) Ревью будет более качественным (мы когда-то даже статистику строили - зависимость времени ревью от размера PR)
А вот для новичка держать контекст прошлой итерации очень сложно, потому - ему поще делать фичу целиком
Согласный!
Больше скажу - факторов влияющих на скорость просто огромное количество.
Но отделить импакт каждого из этих факторов крайне-сложно.
Но что могу точно сказать - влияние именно TBD достаточно большое, и без него результаты точно были бы хуже.
Начал отвечать, но осознал, что понятие "конфликт фич" можно понимать по-разному.
Будет здорово, если уточнишь
Спасибо. Поправлю. Изначально использовал TBD акроним, но сказали не понятно_)
Привет.
Ты путаешь звонки через приложение и звонки через защищенный номер
Подробнее про это мы писали в этой статье https://habr.com/ru/company/avito/blog/665436/
Ну и если кратко - если ты позвонил на подменный номер, и позвонишь на него-же завтра - ты точно так-же дозвонишься до продавца. (при условии что оба звонка у тебя идут с одного и того-же телефона)
Если звонил вчера со своего телефона а сегодня перезваниваешь с телефона жены - есть риск не дозвонится.
какой период а оценки? как часто можно промоутится и менять грейды?
Есть ли какой-то механизм балансировки - за неверно поднятый грейд?
Вообще? или только в первый раз?