Comments 11
Звучит как разумный подход, много где использующийся :)
Только вот «значение поля задается руками через админку» — как-то подозрительно. Очевидный следующий шаг — автоматическое разворачивание по «кольцам» (или как там в ФБ это называется), т.е. фича постепенно включается на Х процентов пользователей, типа там 0-1-10-50-100. И каждый шаг «держится» какое-то время (ну там, день, например), чтобы убедиться, что нет ошибок.
Таким же образом можно не просто новые фичи, но и просто А\Б тестирования проводить.
Ну и, собственно, на графиках у вас count, который непонятно, о чем, лучше бы нормировали к процентам пользователей.
Только вот «значение поля задается руками через админку» — как-то подозрительно. Очевидный следующий шаг — автоматическое разворачивание по «кольцам» (или как там в ФБ это называется), т.е. фича постепенно включается на Х процентов пользователей, типа там 0-1-10-50-100. И каждый шаг «держится» какое-то время (ну там, день, например), чтобы убедиться, что нет ошибок.
Таким же образом можно не просто новые фичи, но и просто А\Б тестирования проводить.
Ну и, собственно, на графиках у вас count, который непонятно, о чем, лучше бы нормировали к процентам пользователей.
но и просто А\Б тестирования проводитьДа, делаем переодически A/B тестирование на флагах, но «руками», приходится писать лишний код для реализации. В новой версии флагов как раз заложен этот функционал.
автоматическое разворачивание по «кольцам»Звучит круто :) думаю мы постепенно дойдем до такого подхода, пока что не много сил тратим на разворачивание.
лучше бы нормировали к процентам пользователейЭто правда, у нас на многих текущих метриках такой подход, начинаем переходить как раз к проценту.
Использовал ещё один подход прии рефакторинга, в частности при выделении микросервисов: запуск двух версий кода, сравнение результатов, логирование различий, отдача старых. Тоже можно только на часть пользователей, по рандому, например.
логирование различийЭто очень важный пункт и я забыл про него сказать в статье, спасибо! В кейсе описанном в метриках мы сравнивали $widgetId полученный по новому и старому подходу и логировали текущее состояние, если они различались. И кстати конкретно в этом кейсе было очень много различий, я уже начал сомневаться, но после дебага оказалось что как раз старый подход отрабатывал не всегда правильно :)
Могу сказать только одно — это работает пока список фиче-флагов маленький и по-дефолту всё выключено. Как только начинается разброс, получаем декартово произведение всех значений флагов как test space для программы. Каждый бинарный флаг удваивает test space, на 10 флагах у вас порядка 1000 комбинаций фичефлагов и никто это не тестирует, т.е. кто-то страдает.
Это теоретическая проблема любого метода поддержания инварианта вариантов.
извиняюсь если оффтоп
как и куда, после изменения параметров/флагов конфига, они пишутся?
файл с переменными окружения под гитом? или вместе с деплоем он обновляется, на каждый сервак, даже находясь вне гита? возможно это темя для отдельного поста))
как и куда, после изменения параметров/флагов конфига, они пишутся?
файл с переменными окружения под гитом? или вместе с деплоем он обновляется, на каждый сервак, даже находясь вне гита? возможно это темя для отдельного поста))
If (Configurator::get('auth_refactoring_percentage') > \random_int(0, 99))
Вместо random_int лучше взять userId, и постепенно раскатывать на всех пользователей
Sign up to leave a comment.
Как раскатывать опасный рефакторинг на прод с миллионом пользователей?