Комментарии 26
Прочитал и получил эстетическое удовольствие. Вы молодцы однозначно.
Начну с самого простого вопроса: почему мы вообще пришли к ежедневным релизам? Ответ очевиден: бизнес хочет «фичи на бою». Таким образом он оценивает динамику разработки. Для разработчиков это тоже удобно. Если система построена на ежедневных релизах, а значит, на небольших изменениях, намного проще и быстрей находить проблемы
Не нахожу убедительными оба ответа.
"Бизнес хочет «фичи на бою». Таким образом он оценивает динамику разработки
Я не понимаю что это значит.
Бизнес хочет видеть бурную деятельность, и вы всем штатом её предоставляете, "на все деньги"? В моём представлении бизнес интересует динамика прибыли.
Больше релизов != больше денег
Если система построена на ежедневных релизах, а значит, на небольших изменениях, намного проще и быстрей находить проблемы
Больше релизов = больше багов.
И ведь действительно: в погоне за частотой релизов и скоростью вы неизбежно их создаёте, а потом героически преодолеваете.
И вроде бы все довольны: бизнесу приятно видеть бурную деятельность "на все деньги", менеджменту приятно набивать KPI (раздробив один нормально оттестированный и продуманный крупный релиз на десятки маленьких), но все равно попахивает.
Или я чего-то сильно не понимаю, или это какой-то слишком эффективный менеджмент, за гранью здравого смысла
xxx: Посмотрите на этот чудесный восходящий график! В этом месяце мы закрыли в 10 раз больше тикетов, чем во всем прошлом! Мы эффективны!
yyy: В прошлом месяце тикетов было в 20 раз меньше
Больше релизов = больше багов.
в погоне за частотой релизов и скоростью вы неизбежно их создаёте
Больше релизов - это уменьшение размера каждого релиза. Не вижу причин увеличения количества багов от того, что вместо 1 деплоя на 10 фич стало 10 деплоев по одной.
Но слишком эффективным менеджментом тут за версту пахнет.
Не вижу причин увеличения количества багов от того, что вместо 1 деплоя на 10 фич стало 10 деплоев по одной
Обычно погоня за количеством+скоростью заканчивается примерно так:
feature1Output(){
return "whatever business wants";
}
feature1OutputTest(){
return assertEquals("whatever business wants", feature1Output());
}А потом они уходят (с)
Соблазн релизить не фичи, а выходные требования растёт пропорционально уровню давления. Соответственно, потом придётся сшивать все это в хоть сколько-нибудь работающую систему.
В этом и причина роста количества багов: не в том, что быстро релизиться научились, а в том что появляется такое требование.
Утрирую, конечно. На мой взгляд сама гонка за количеством релизов — ложная.
Здесь релизят не быстро, а часто. А требование делать это часто вполне себе обосновано как с технической, так и с продуктовой стороны.
Есть некоторые недостатки, да. Недостатки есть и у больших релизов. На которые тоже может оказываться давление: график поставок определен, список обязательных фич тоже. И нужно успеть :)
Так смысл же не в том, что фичи бьются на куски по 1 дню разработки, а в том, что они доставляются тогда, когда готовы.
Сама фича может и месяц разрабатываться, особенно, если её невозможно релизить в несколько частей и в реализации задействовано несколько разных команд задействовано -- бэк, фронт и т.п. Но доставляться на бой будет без недельного ожидания следующего релиза. Обычный CI/CD. Но конечно большие фичи стоит всё-таки избегать.
В статье не говорится что ежедневные релизы нужны всем, а скорей пытается ответить на вопрос как к ним прийти если это нужно. Возможность быстро проверять гипотезы и реагировать на изменение рынка это конкурентное преимущество, для некоторых бизнесов, на мой взгляд.
И ведь действительно: в погоне за частотой релизов и скоростью вы неизбежно их создаёте, а потом героически преодолеваете.
Гонки нет, это совершенно будничный процесс. Если изменения готовы, то незачем ждать условного релиза через месяц, если можно вылить их сейчас. У нас каждый день есть небольшие улучшения которые выкатываются на продакшн.
Если бизнес оценивает KPI в кол-ве задач это грустно. Но это не наш случай.
У нас каждый день есть небольшие улучшения которые выкатываются на продакшн
можете привести пример такого улучшения, которое вы делаете за день?
это точно улучшения, а не хотфиксы сырого релиза, которым вы так спешили поделиться с пользователем/бизнесом, который оценивает динамику разработки?
пользователям точно нужно, чтобы каждый день их UX улучшали?
пользователи точно считают эти ежедневные изменения улучшениями?
я вот боюсь банковское приложение обновлять, потому что каждый раз его улучшают так, что я нужные мне функции ищу каждый раз как в первый
Как вы измеряете продуктовые метрики как зависимость от фичей?
Добрый день! Есть дашборды с продуктовыми метриками, гипотезы проверяются а/б тестами.
Вы не поняли вопрос.
У вас есть фича, вы хотите проверить изменения показателей (например: воронки регистраций и продаж, которые могут состоять из нескольких этапов).
Для этого вам нужно делать А/Б-тестирование. Причем оно должно идти достаточно долго, чтобы график стабилизировался. Если фича не особо популярна, то ветку должны запускать на большой аудитории (и такой же объем в контрольную группу). Плюс проблема плохих результатов.
АБТ эксперимент из ветки — это исключение. Обычно новую фичу закрывают флагом и открывают во время АБТ.
Суть моего вопроса от этого не меняется. Да и ответ я знаю: там так никто не оценивает влияние фичей на финансовые показатели. Но зато «измеряют» эффективность линейного персонала.
Финансовые показатели — это супер нечувствительная метрика. Есть, конечно, исключения типа изменений, связанных с рекламой или если сайт занимается продажами. Но в массе свой, например, более удобный способ написания комментов на Хабре скорей всего не прокрасит деньги, но может прокрасить time spent.
Поэтому в общей массе придумывают другие метрики, которые поддерживают видение того, как должен развиваться продукт. Если всем ок такие метрики, то в чем проблема?
Мой вопрос все же относится к контексту проекта.
Согласен: чувствительность - показатель производный от времени эксперимента и количества пользователей. Отсюда и другие метрики.
Но суть тут в другом, финансовые и около-финансовые показатели могут как улучшиться, так и ухудшиться: из-за особенностей ui/ux, багов или нагрузки, не говоря уже о влиянии функционала.
Для бизнеса я вижу плюсы в относительно редких релизах, начиная с определённого этапа роста пользовательской базы в highload.
Но как разработчик, я против них :) Меня они демотивируют.
Кстати, по Sentry есть русскоязычный чат https://t.me/sentry_ru
А можете, пожалуйста, немного подробнее рассказать про скриншот тестирование? Какой сервис используйте для сравнения скриншотов? Насколько удобно апрувить и коммитить ожидаемые ченжи? Как это встроено в CI? Как это отображается в мерж-реквестах?
Да, конечно! Большинство скриншот тестов, делаем с помощью playwright и @playwright/test.
Для скриншот тестов есть билд в CI (teamcity). Билд автоматически запускается на каждой ветке. В нем сначала поднимается витрина компонентов (react-styleguidist), а потом playwright заходит на страницы компонентов и фоткает все примеры. Внутри @playwright/test есть хелпер toMatchSnapshot который сравнивает скриншоты и в случае если они не совпадают создает картинку с дифом. В playwright v1.16.0 завезли html репортер, мы еще не успели его прикрутить и смотрим дифы картинок в артефактах в CI если что-то пошло не так.
Для обновления скриншотов в CI предусмотрен отдельный билд, который можно запустить на нужной ветке. Это те же тесты, но с флагом, который обновляет скриншоты при необходимости. Далее билд с новыми картинками делает комит в ветку. В пул-реквестах видно что поменялось тк картинки хранятся рядом с кодом под git lfs.
При необходимости, скриншотные тесты и обновление скриншотов можно запустить локально в докере для всех компонентов или для конкретного.
Руками тесты писать не нужно. Новые тесты автоматически появляются после добавления в витрину нового примера или компонента. Для этого сделан небольшой скрипт, о котором речь в статье. Также есть возможность отключить тесты для компонента/примера.
А как вы решаете такую проблему?:
Пользователь открыл вкладку с SPA и ушел в гибернацию на пару дней. А в это время SPA зарелизился. После включения компьютера, у пользователя открыт старый код со старыми предзагруженными ресурсами. И пока он сам не сделает F5 - ресурсы не перезагрузяться.
Релизим фронтенд несколько раз в день