Что такое фича фриз релиза
Что такое feature toggle или как избавиться от мучительных мёржей и долгоживущих веток?
Проблема
Представьте, что циклы разработки вашей команды длятся по две недели, а реализация новой фичи потребует от команды 3 месяца разработки. На первый взгляд, есть две возможные схемы действий:
Использование feature switcher-ов для решения проблем
Такая проблема встречается в разработке довольно часто и есть изящное решение, позволяющее взять лучшее от описанных выше подходов — feature toggle или feature switcher.
По сути, feature switcher — это boolean флаг, который хранится в базе данных и содержит информацию о том, должна быть включена та или иная фича или нет. Значение этого флага может быть извлечено из базы данных по ключу. Удобство использования feature switcher-ов заключается в том, что они могут быть легко изменены бизнес-пользователем во время runtime через панель администратора без необходимости заново деплоить приложение.
Ниже приведен пример использования feature toggle на языке Java:
В примере выше configurationManager — это класс, позволяющий извлечь значение определенного feature switcher-а из базы данных по его ключу.
Также, при помощи feature switcher-ов, можно отображать/скрывать определенные элементы на фронтенде. Для этого придется положить значение флага в Model и передать его на View как это показано ниже:
После чего использовать переданное значение для рендеринга того или иного HTML кода:
Виды feature switcher-ов
Описанный концепт использования feature switcher-ов — это лишь один возможный случай использования и такие feature switcher-ы называются release toggles. Всего выделяют 3 разных вида feature switcher-ов:
Проблемы использования feature toggle-ов
Поскольку я работаю на проекте, где активно используются feature toggle-ы, то кроме очевидных достоинств их использования я начал замечать и проблемы, связанные с ними:
Решения некоторых из описанных проблем
Помочь решить вышеописанные проблемы могут следующие действия:
Итоги
Feature switcher — очень простой и одновременно мощный механизм, позволяющий избегать монструозных коммитов, легко менять поведения приложения или собирать несколько разных приложений на одной кодовой базе, используя разную конфигурацию feature toggle-ов.
Однако, стоит также помнить, что этот паттерн разработки имеет некоторые недостатки, которые выливаются в трудночитаемый и трудно поддерживаемый код, поэтому следует избегать чрезмерного использования этого паттерна и периодически проводить документирование feature switcher-ов и их ревизию, чтобы удалять неиспользуемые и, как следствие, очищать проект от “мёртвого” кода.
23 признака того, что ты работал в «Яндексе» — из личного опыта маркетолога Андрея Чеботарева
Крымчанин Андрей Чеботарев проработал в московском «Яндексе» почти полтора года на должности маркетолога API «Яндекс.Карт». Недавно он закончил свою карьеру в российской компании и вернулся в Украину. Помимо магнитиков на холодильник, Андрей привез в Украину множество удивительных историй из московского офиса «Яндекса». Своими наблюдениями о нескучных буднях в компании он согласился поделиться с читателями AIN.UA. А поскольку они известны лишь «яндексоидам», получился список настоящих инсайдов.
Селфи Чеботарева в «яндексовском» лифте
Ты работаешь/работал в Яндексе, если…
…точно знаешь, что сегодня не среда, потому что по средам на кофепоинте глазированные сырки. На кофепоинтах много всего — начиная с кофе с печеньками и заканчивая свежими фруктами и овощами, которые хозяюшки приносят каждый обед. Но среда особенный день. По средам с самого утра яндексоидов ждут глазированные сырки. Это касается московского офиса, так как в других городах сырки могут быть в другой день, например в Санкт-Петербурге они по понедельникам.
…помнишь, что разработка измеряется человеко—месяцами и хоть раз видел Jira в Read only. Человеко-часы и даже дни — это не про разработку в «Яндексе». Проекты тут обычно оценивают в человеко-месяцах. Jira — это трекер задач, который раньше использовали в «Яндекс». Но мы были настолько большие, что у нас она постоянно висла. Поэтому режим Read only в Jira — это была притча во языцех, пока почти все не перешли на трекер собственной разработки «Стартрек».
» data-medium-file=»https://ain.ua/wp-content/uploads/2015/04/10644785_559090620884864_59254426679170307_o-150×84.jpg» data-large-file=»https://ain.ua/wp-content/uploads/2015/04/10644785_559090620884864_59254426679170307_o-1024×576.jpg» loading=»lazy» src=»https://ain.ua/wp-content/uploads/2015/04/10644785_559090620884864_59254426679170307_o-e1428403747313.jpg?x82322″ alt=»Рабочее место Чеботарева» width=»725″ height=»408″ />
Рабочее место Чеботарева
…провел день полностью во встречах с самого утра до позднего вечера. Нет, конечно не каждый и не у всех. У большинства разработчиков календари почти чисты. Но вот менеджеры или руководители действительно проводят очень много времени в переговорках на разнообразных встречах. Расписание каждого конкретного сотрудника отображается на его персональной странице, и там же нужному тебе человеку можно назначить встречу.
…будил администратора в одиннадцать утра, чтобы узнать, кто вчера вечером катил и почему все сломалось. Иногда утром включается режим «все сломалось» (на самом деле не все, конечно же). Так бывает. В таком случае нужно понять, почему все сломалось. Обычно это бывает, если кто-то вчера, что-то выкладывал в продакшн, то есть катил (внутрияндексовский сленг — ред.). Этим занимаются админы, и они лучше всего знают кто и что катил.
…заставал завтрак в столовой. Вкусно, но смысл? В столовой «Яндекса» до 11 утра можно съесть очень вкусный завтрак. После 11 меню меняется. Но 11 утра — это очень рано. Обычно старт рабочего дня начинается не раньше полудня, т о есть в 11 большей части офиса нет на работе.
…слышал страшные истории про выкладку в продакшн после фича фриза. Фича фриз — это время с 15 декабря до конца праздников. Если коротко — то в это время нельзя ничего катить, потому что скоро праздники. Но каждый год находятся менеджеры, которые обходят этот запрет и катятся, потому что очень надо (правда очень надо), в результате случаются казусы, о которых я не могу рассказать. Но если ваша работа связана с большим количеством пользователей — лучше никогда не делать релизов перед праздниками и выходными, целее будете.
…пробовал уговорить катиться в пятницу после обеда, потому что очень надо еще вчера. В пятницу тоже нельзя делать релизы, потому что работать в выходные не очень хочется.
…пытался найти переговорку «Оксфорд» или «Гарвард». Большинство сотрудников работает в open space, поэтому все общение о работе проходит в переговорках. Часто найти свободную в час пик бывает проблемой, даже несмотря на то, что общее количество переговорок переваливает за сотню. В цокольном этаже БЦ «Мамонтов» (один из корпусов, которые занимает «Яндекс» в Москве) есть классы для обучения в ШАДе (Школа анализа данных). Именно эти переговорки почти всегда пустуют, но их сложнее всего найти.
…получал в день больше писем, чем за месяц жизни до «Яндекса». Почты действительно много. Если вы привыкли не сортировать почту, то вам (особенно если вы менеджер) будет очень сложно, так как почта — основной вид коммуникации.
…ставил таски сам на себя и потом не мог вспомнить, что по ним надо сделать и откуда они вообще взялись. Это удобно. Чтобы не забывать что-то сделать ты можешь поставить задачу сам на себя. Главное не забыть ее для себя же подробно описать, иначе может случиться, что когда ты к ней вернешься, то не сможешь вспомнить, что ты имел ввиду и зачем это вообще надо.
…неистово, до последнего комментария, защищал правду в «этушке». «Этушка» — это система внутренних блогов, которые доступны только во внутренней сети, то есть писать туда могут только сотрудники компании. Писать можно о чем угодно. Топ записей делится на записи о работе и о жизни. В «Этушке» можно писать обо всем, даже о политике. Как и в любой блогосфере, тут регулярно возникают трения, а учитывая, что сеть только для сотрудников «Яндекса» (то есть люди прошли определенный отбор), то и трения иногда получаются просто эпическими.
…проверял не лайкнул ли твой пост Волож. Я лично знаком с человеком, пост которого он лайкал.
…водил друзей на экскурсию в офис и рассказывал им, как тут классно работается. В офис можно приводить друзей, для этого достаточно на ресепшене взять специальный бейджик «Я гость» или «Я гостья». За полтора года я провел, наверное, пару десятков экскурсий и успел выработать оптимальный маршрут.
…назначал встречу с названием тимбилдинг, праздник или просто пьянка. По вечерам в пятницу в переговорках можно легко встретить людей, которые играют в настольные игры, карты или StarCraft. Развлекаться в офисе тоже никто не запрещает, например, ежегодный новогодний корпоратив проводится именно в офисе. А ведь еще есть дни рождения, повышения, прощания и много других приятных поводов.
…работал на балконе в «Морозове». БЦ Морозов — это еще один корпус офиса «Яндекса» в Москве. В Морозове почти на каждом этаже есть балконы (а на некоторых этажах вообще большие террасы) на которых в теплое время года удобно работать и отдыхать.
…ел трубочки со сгущенкой в кафе Лебедева. Они правда очень вкусные.
…бегал в одной футболке зимой между корпусами. Иногда встречи идут подряд и в разных корпусах. Тогда надо быстро переместиться из одного корпуса в другой. К сожалению, подземных тоннелей между ними нет (или их от нас скрывали) и приходится бежать по улице.
…тратил «карточку» на пиво в «Джон Донне». На бейджик (карточка сотрудника) ежемесячно начисляют деньги на еду, которые можно потратить в столовой на обеды, но еще их принимают в ряде заведений рядом с офисом, например в пабе «Джон Донн», в ресторане «Изя Гриль» или Starbucks. Если не следить за расходами, то можно легко уйти в минус.
…знаешь, что такое «можешь пикать» и «пикни пожалуйста». «Можешь пикать» — это в кафе Лебедева, когда уже сделал заказ, можешь пикнуть и оплатить его (приемник карточек издает звук). А «пикни пожалуйста» — это в helpdesk (там где выдают технику и помогают ее настроить), чтобы у них был учет, кто пришел, что просил и взял (например, еще одну зарядку для ноутбука).
…забывал подписать командировочный лист после командировки. Наверное, это единственный остаток бюрократии. В командировках надо ставить печати на выданное в отделе кадров командировочное удостоверение.
…пытался провести встречу в 11 утра. Назначать встречи на 11 утра без предварительного согласия считается дурным тоном.
…ты любишь пользователей и тебе нравится то, чем ты занимаешься. Это действительно так. У HR’ов компании как-то получается набирать людей, которые действительно горят и болеют продуктом и счастьем пользователя. Для нас в «Яндексе» это никогда не было пустым звуком: это краеугольный камень разработки — счастье пользователя.
…хоть раз пользовался «Яндекс.Браузером», а после увольнения поставил Chrome, но радости никакой. Chrome действительно нельзя использовать для доступа ко внутренней сети компании, но не потому что Google, а потому что Chrome. В него встроены модули, которые помогают индексировать страницы, которые загружаются браузером, а во внутренней сети все секретно. «Яндекс.Браузером» (как и «Яндекс.Диском», «Яндекс.Картами», «Яндекс.Деньгами») никто не заставляет пользоваться. Пользуйся тем, что тебе больше по вкусу. Лично я привык к «Яузеру» и он мне нравится, особенно с интересом я смотрю на новую экспериментальную версию с минималистичным дизайном.
Релизим фронтенд несколько раз в день
Комментарии 26
Прочитал и получил эстетическое удовольствие. Вы молодцы однозначно.
Начну с самого простого вопроса: почему мы вообще пришли к ежедневным релизам? Ответ очевиден: бизнес хочет «фичи на бою». Таким образом он оценивает динамику разработки. Для разработчиков это тоже удобно. Если система построена на ежедневных релизах, а значит, на небольших изменениях, намного проще и быстрей находить проблемы
Не нахожу убедительными оба ответа.
«Бизнес хочет «фичи на бою». Таким образом он оценивает динамику разработки
Я не понимаю что это значит.
Бизнес хочет видеть бурную деятельность, и вы всем штатом её предоставляете, «на все деньги»? В моём представлении бизнес интересует динамика прибыли.
Если система построена на ежедневных релизах, а значит, на небольших изменениях, намного проще и быстрей находить проблемы
Больше релизов = больше багов.
И ведь действительно: в погоне за частотой релизов и скоростью вы неизбежно их создаёте, а потом героически преодолеваете.
И вроде бы все довольны: бизнесу приятно видеть бурную деятельность «на все деньги», менеджменту приятно набивать KPI (раздробив один нормально оттестированный и продуманный крупный релиз на десятки маленьких), но все равно попахивает.
Или я чего-то сильно не понимаю, или это какой-то слишком эффективный менеджмент, за гранью здравого смысла
xxx: Посмотрите на этот чудесный восходящий график! В этом месяце мы закрыли в 10 раз больше тикетов, чем во всем прошлом! Мы эффективны!
yyy: В прошлом месяце тикетов было в 20 раз меньше
Больше релизов = больше багов.
в погоне за частотой релизов и скоростью вы неизбежно их создаёте
Но слишком эффективным менеджментом тут за версту пахнет.
Не вижу причин увеличения количества багов от того, что вместо 1 деплоя на 10 фич стало 10 деплоев по одной
Обычно погоня за количеством+скоростью заканчивается примерно так:
А потом они уходят (с)
Соблазн релизить не фичи, а выходные требования растёт пропорционально уровню давления. Соответственно, потом придётся сшивать все это в хоть сколько-нибудь работающую систему.
В этом и причина роста количества багов: не в том, что быстро релизиться научились, а в том что появляется такое требование.
Утрирую, конечно. На мой взгляд сама гонка за количеством релизов — ложная.
Здесь релизят не быстро, а часто. А требование делать это часто вполне себе обосновано как с технической, так и с продуктовой стороны.
Есть некоторые недостатки, да. Недостатки есть и у больших релизов. На которые тоже может оказываться давление: график поставок определен, список обязательных фич тоже. И нужно успеть 🙂
Так смысл же не в том, что фичи бьются на куски по 1 дню разработки, а в том, что они доставляются тогда, когда готовы.
Большие фичи, бьются на несколько частей, и завозятся на прод поэтапно.
В статье не говорится что ежедневные релизы нужны всем, а скорей пытается ответить на вопрос как к ним прийти если это нужно. Возможность быстро проверять гипотезы и реагировать на изменение рынка это конкурентное преимущество, для некоторых бизнесов, на мой взгляд.
И ведь действительно: в погоне за частотой релизов и скоростью вы неизбежно их создаёте, а потом героически преодолеваете.
Гонки нет, это совершенно будничный процесс. Если изменения готовы, то незачем ждать условного релиза через месяц, если можно вылить их сейчас. У нас каждый день есть небольшие улучшения которые выкатываются на продакшн.
Если бизнес оценивает KPI в кол-ве задач это грустно. Но это не наш случай.
У нас каждый день есть небольшие улучшения которые выкатываются на продакшн
можете привести пример такого улучшения, которое вы делаете за день?
это точно улучшения, а не хотфиксы сырого релиза, которым вы так спешили поделиться с пользователем/бизнесом, который оценивает динамику разработки?
пользователям точно нужно, чтобы каждый день их UX улучшали?
пользователи точно считают эти ежедневные изменения улучшениями?
я вот боюсь банковское приложение обновлять, потому что каждый раз его улучшают так, что я нужные мне функции ищу каждый раз как в первый
‘можете привести пример такого улучшения, которое вы делаете за день?’
ежедневные релизы это больше про независимую множества разных улучшений по мере готовности. Что не надо всем принудительно синхронизироваться и выводить 7 фичей дней во второник. А каждый может вывести фичу в свой день
так понятно, спасибо
Как вы разбиваете фики на таски так, чтобы каждый день релизиться?
Чтобы релизиться каждый день, не обязательно всё делить на маленькие фичи. Вот на скрине иллюстрация того, как каждый день есть что релизить, но что-то делается за 30 минут, а что-то 4 дня.
Как вы измеряете продуктовые метрики как зависимость от фичей?
Добрый день! Есть дашборды с продуктовыми метриками, гипотезы проверяются а/б тестами.
Вы не поняли вопрос.
У вас есть фича, вы хотите проверить изменения показателей (например: воронки регистраций и продаж, которые могут состоять из нескольких этапов).
Для этого вам нужно делать А/Б-тестирование. Причем оно должно идти достаточно долго, чтобы график стабилизировался. Если фича не особо популярна, то ветку должны запускать на большой аудитории (и такой же объем в контрольную группу). Плюс проблема плохих результатов.
АБТ эксперимент из ветки — это исключение. Обычно новую фичу закрывают флагом и открывают во время АБТ.
Суть моего вопроса от этого не меняется. Да и ответ я знаю: там так никто не оценивает влияние фичей на финансовые показатели. Но зато «измеряют» эффективность линейного персонала.
Финансовые показатели — это супер нечувствительная метрика. Есть, конечно, исключения типа изменений, связанных с рекламой или если сайт занимается продажами. Но в массе свой, например, более удобный способ написания комментов на Хабре скорей всего не прокрасит деньги, но может прокрасить time spent.
Поэтому в общей массе придумывают другие метрики, которые поддерживают видение того, как должен развиваться продукт. Если всем ок такие метрики, то в чем проблема?
Мой вопрос все же относится к контексту проекта.
Но суть тут в другом, финансовые и около-финансовые показатели могут как улучшиться, так и ухудшиться: из-за особенностей ui/ux, багов или нагрузки, не говоря уже о влиянии функционала.
Для бизнеса я вижу плюсы в относительно редких релизах, начиная с определённого этапа роста пользовательской базы в highload.
Но как разработчик, я против них 🙂 Меня они демотивируют.
Кстати, по Sentry есть русскоязычный чат https://t.me/sentry_ru
А можете, пожалуйста, немного подробнее рассказать про скриншот тестирование? Какой сервис используйте для сравнения скриншотов? Насколько удобно апрувить и коммитить ожидаемые ченжи? Как это встроено в CI? Как это отображается в мерж-реквестах?
Не знаю, что за решение использует автор, но лично я смотрю в сторону Loki.
По поводу удобства не знаю, можете предварительно оценить по этому докладу (где-то в середине будет демонстрация Loki)
Да, конечно! Большинство скриншот тестов, делаем с помощью playwright и @playwright/test.
Для скриншот тестов есть билд в CI (teamcity). Билд автоматически запускается на каждой ветке. В нем сначала поднимается витрина компонентов (react-styleguidist), а потом playwright заходит на страницы компонентов и фоткает все примеры. Внутри @playwright/test есть хелпер toMatchSnapshot который сравнивает скриншоты и в случае если они не совпадают создает картинку с дифом. В playwright v1.16.0 завезли html репортер, мы еще не успели его прикрутить и смотрим дифы картинок в артефактах в CI если что-то пошло не так.
Для обновления скриншотов в CI предусмотрен отдельный билд, который можно запустить на нужной ветке. Это те же тесты, но с флагом, который обновляет скриншоты при необходимости. Далее билд с новыми картинками делает комит в ветку. В пул-реквестах видно что поменялось тк картинки хранятся рядом с кодом под git lfs.
При необходимости, скриншотные тесты и обновление скриншотов можно запустить локально в докере для всех компонентов или для конкретного.
Руками тесты писать не нужно. Новые тесты автоматически появляются после добавления в витрину нового примера или компонента. Для этого сделан небольшой скрипт, о котором речь в статье. Также есть возможность отключить тесты для компонента/примера.