Comments 8
Только по итогам одного квартала примерно в два раза сократилось количество простоев, а Time to market вырос в 10 раз. Параметр Cycle Time у нас составлял 50, сейчас он равен примерно 15–20. Частота релизов (Change Frequency) вначале равнялась 30, теперь она достигла планки в 100. Результаты реально серьёзно улучшились: мы чаще релизимся, меньше откатываемся и быстрее делаем свои задачи.
Звучит, конечно, сильно. Change Frequency = 100 это тоже по результатам одного квартала? Речь именно о полноценных релизах или хотфиксы тоже включены?
Сначала испытываем на фокус-группе (например, на себе любимых), потом на 1 % всех клиентов, потом 10 % и далее 50 – 80 – 100 %
Какие временные интервалы между переходами?
Звучит, конечно, сильно. Change Frequency = 100 это тоже по результатам одного квартала? Речь именно о полноценных релизах или хотфиксы тоже включены?
По change frequency я бы сказал был более долгий и плавный переход. Около полугода или больше. Тюнили пайплайны, какие то этапы отправляли в параллель.
В самой метрике учитываются любые поставки на prod. По сути фича и хотфикс ничем не отличаются - в обоих случаях делается поставка нового кода на прод, поэтому для нас это все попадает в метрику change frequency.
Какие временные интервалы между переходами?
Сильно зависит от фичи. Что то супер критичное, может и неделю раскатываться плавно.
Какие то менее критичные изменения, которые несут небольшие риски влияния на клиентов могут быть раскатаны за несколько часов.
А какой сейчас показатель Change Failure Rate?
Крайне низкий, не больше 5 в квартал на наших масштабах. Но тут есть нюансы. Деплой по blue/green с canary раскаткой позволяет не оказывать никакого влияния на клиентов, даже если он неудачный. Такие кейсы не попадают в статистику Change Failure.
Но все же, бывают неудачные релизы и в этом случае, после переключения бОльшего процента трафика в грин. Вот такие да, увеличиваются счетчик фейлов, но повторюсь - таких кейсов крайне мало.
Подскажите, релизы БД каким-то образом удалось затянуть в описанную концепцию? Если нет, то было бы здорово узнать, как у вас решаются задачи, связанные с релизами БД.
Что подразумевается под релизами БД? Накат новой версии PostgreSQL?
Чтобы новые сервисы могли писать куда-то новые данные, нужно добавлять в таблицы колонки, создавать новые таблицы, удалять старые. Модифицировать хранимые процедуры, функции и триггеры, если применяются.
Но, видимо, вопрос задан не по адресу.
В общем, вы про изменение схем, зачастую необратимые.
В нашей схеме СУБД одна на оба спейса и блю и грин. Слишком много мороки с двумя активными инстансами постгрес, поэтому этим путем мы не пошли, принимая все недостатки такого подхода.
Ну и мы стараемся по максимуму исключить breaking changes со схемой данных БД. Не переименовывать колонки, а добавлять новые, не удалять старые и т.д. В 90% случаев, ломающих изменений можно избежать.
Если же все таки без них никак, то такие работы проводятся в неактивно для клиентов время. И держим под рукой скрипты отката, которые должны быть обязательно.
Как мы снизили Cycle Time и увеличили Change Frequency