Комментарии 14
Это всё замечательно, но, копируя Дороти Маха из "Револьвера" Гая Ричи, бизнес спрашивает: "Что это даёт мне?"
Я показывал эти метрики нашему CTO и нашему CEO (по сути статья написана из материалов, которые я показывал им). Оба ответили, что ценность качественного конвейера поставки теперь очевидна и дали добро на дальнейшие работы по его прокачке.
Когда мы начали поставлять без факапов, перестали срывать сроки и порешали проблемы, до которых раньше просто не доходили руки - а всего этого мы добились - бизнес это еще как оценил. А с цифрами метрик еще и понятно где мы сейчас, а куда можем прийти если приложим еще усилия.
И, например, security упомянутый в статье, и до которого мы раньше никак не могли добраться, имеет вполне материальное выражение. Внешние аудиторы выставляют security rating нашей компании и это:
Имидж нашего продукта перед клиентами
Имидж компании перед инвесторами
Прямое влияние на стоимость страховки от security-рисков.
Хм, но DORA метрики, на самом деле, ни с чем не коррелируют (там исследование не может ничего доказать, так как сделано некорректно).
Реально я вижу переход к относительно современной модели бранчевания, но этот подход очевиден уже при первом взгляде на старую модель. Зачем тут DORA?
P.S. Но да, DORA может использоваться для убеждение не слишком компетентного менеджмента для проведения достаточно очевидных изменений в пайплайне. Другой ценности в метриках нет.
А вы можете более развёрнуто рассказать, в чем некорректность исследования? Ну или ссылкой поделиться.
По поводу модели бранчевания как главной причины - не совсем. Главным изменением было снятие избыточной нагрузки на e2e-тесты, как на главный bottleneck.
Ну и касательно очевидности. Вы знаете, когда все позади, и когда мы говорим только о применённом решении, то и правда кажется очевидным. Но так не было "внутри событий". У этого феномена даже отдельное название есть - hindsight bias, это одно из когнитивных искажений. Из-за него же человечество никогда не увидит объективных учебников истории, например.
Когда находишься внутри событий и у тебя прод разваливается, тесты флакуют, кучи legacy кода, задачи горят, люди горят, то лишняя ветка совсем не кажется важной :) Я уж не говорю о том, что я команду уговорил от этой ветки отказаться не с первого раза.
И вот тут как раз DORA-метрики и спасают, потому что они помогают в нужную сторону посмотреть, найти за какую ниточку начать вытягивать. И найти общий язык с окружением, чтобы за нужную ниточку всем вместе и потянуть.
Про DORA. Там проблемы в сборе самих метрик (их присылали произвольные люди по собственной инициативе, без какой-то верификации данных, без определения представительности присланных данных, даже без соотношения данных с конкретными департаментами компаний), проблемы в отслеживании корреляций (не было анализа кластеризации по секторам, не оценивалась вообще важность для бизнеса метрик, некоторые метрики вообще не могут быть оценены для многих компаний). Ну и "корреляция не значит каузация".
Так что говорить о какой-то большей обоснованности метрик DORA, нежели, например, натальной карты сервера - не приходится.
По поводу очевидности - тут как раз используемые решения были очевидно первыми, в том числе и для улучшения метрик. Но при этом же метрики никак с изменением подхода к бранчам не связаны, для улучшения метрик могли и еще десяток тестовых кластеров поставить, например.
Но вы правильно пишите, что метрики нужны для убеждения - да, в этом они помогают.
Замечания справедливы, но для меня они не списывают ценность исследования в ноль.
Проблема представительности свойственна любым большим исследованиям. Но какие есть разумные альтернативы?
По поводу "корреляция не значит каузация" - это верно. Но есть ли (и возможны ли) исследования, подтверждающие причинно-следственную связь, а не корреляцию, для качественных показателей, тем более в таких сложных процессах, как разработка ПО?
По такой логике все исследования вроде уровня безопасности, образованности населения, социальной справедливости, уровня коррупции, индекса счастья, потребительских ожиданий - бесполезны.
Для меня все это поводы не воспринимать результаты исследования как догму и продолжать думать своей головой. Но не повод отбросить результаты как бесполезные.
Принимать решения имея в арсенале цифры+ориентиры+собственный опыт это лучше, чем принимать решения, имея только собственный опыт.
Хм, проблемы представительности как раз не представляют особой проблемы. Достаточно просто собирать данные не в режиме "пришлите кто-нибудь", а через обращения в компании согласно статистическим данным (хотя бы по размеру и по отраслям), впрочем есть и куча других подходов. Верификацию-то уж точно стоило бы сделать. Как и глубинные интервью хотя бы с некоторыми компаниями (лучше с каким-то представительным количеством). Но ничего из этого не делалось, так как, кажется, цели сделать что-то обоснованное - не ставилось.
Проверку каузации вполне можно сделать - например посмотреть, как меняется доходность в компаниях с резким изменением метрик (причем тоже с разным размерами и из разных отраслей). Скорее всего финансовые показатели при этом не изменятся.
(Кстати, так как больше всего делилось данными люди из крупных компаний, где реально скорость доставки имеет смысл и легче обеспечиваются - то корреляция выглядит очевидной. Но понятно, что доставку 10 релизов в день в компании в 10 человек нет смысла делать. Впрочем, кажется, там и успех компаний считали абсолютные, а не в привязке на сотрудника, что уже совсем бессмысленно).
И да, конечно индексы счастья или коррупции - бесполезны и не дают никакой полезной информации и не обладают никакой прогностической силы.
Опираться на свой опыт - да, есть смысл!
Спасибо, что поделились опытом. Полезная пища для размышлений.
~28 запусков). Каждый запуск это 30-90 минут. Итого ~4 рабочих дня.
Какая-то странная арифметика. Сборка только в рабочее время идёт?
Да, это арифметика по рабочему времени. Пайплайн, конечно, можно запустить и ночью. Но в изначальной реализации это мало помогало. Во-первых, тесты часто падали. Во-вторых, как я писал в статье, e2e-тесты можно запустить только одни за раз. А у билдов в CI таймауты настроены. Поэтому, запустив вечером 14 сборок сервисов, утром прийти и увидеть их все прошедшими было не очень-то реально.
Отказ от develop в многосервисной архитектуре? Это как?
У вас в работе 25 задач в одном спринте, допустим. 10 из них деплоятся в прод вместе, 8 других тоже вместе, а остальные 7 вообще хотфиксы. Что вы делаете?
У нас (теперь) нет спринтов и мы просто катим задачу на прод как только она готова. Ну или закрываем feature flag-ом и все равно катим, но такое бывает довольно редко. В такой схеме в develop, как в буфере перед релизом, просто нет необходимости. Сделали - релизим, стараемся в continuous delivery.
Если у вас 10 задач должны ехать на прод вместе, то, вероятно, мы с вами просто по-разному делим на задачи. У нас задача это либо цельный кусок ценности для пользователя (который уже довольно автономен по определению), либо как раз отдельно деплоящийся кусок технической работы (тоже автономный по определению). Поэтому связки на такое количество задач, как вы описали, у нас просто не возникает. У нас даже на 2 задачи связка это большая редкость.
Если вы расскажете, что у вас под задачей понимается, то я, вероятно, смогу на ваш вопрос полностью ответить.
У нас 25 микросервисов. В фичах задействованы в разных пропорциях разные сервисы, в среднем релизе их 7-8. Также есть хотфиксы, которые прилетают как бог на душу положит
Понял.
В таком случае hotfix-ы можно раскатывать делая hotfix-ветку от master, а потом сливая обратно в develop. Но, полагаю, вы уже так и делаете.
А от develop в вашем случае да, не избавиться.
Если принимаете советы, то я бы посоветовал вам вот что сделать:
Оцените дизайн ваших микросервисов. Тот факт, что вам приходится ради одной задачи менять сразу несколько сервисов намекает на то, что сервисы распилены не очень удачно и кодовые базы у сервисов разделены, но связность между ними осталась высокой.
Оцените, действительно ли сервисы надо катить вместе или можно выкатывать каждый отдельно, сохраняя рабочим прежний контракт. Версионирование API и contract testing тут могут сильно помочь.
Посмотрите, возможно вам будет проще если переехать в монорепозиторий. Решение специфическое, но в некоторых случаях полезное.
Четыре метрики, изменившие мой проект