В Райффайзен Банке 14 профессиональных сообществ и 262 Agile-команды. Все эти люди взаимодействуют между собой, создают артефакты и проекты с разной скоростью, качеством и своими решениями. Чтобы все это не превратилось в хаос, мы начали выстраивать инженерные практики — для унификации/стандартизации решений.
В этой статье поделюсь нашим топ-5 инженерных практик, которые помогают держать проекты под контролем, быстрее деплоить фичи и снижать клиентскую боль — с конкретными цифрами, как это влияет на бизнес-результат. Если вы хотите построить сильную инженерную культуру — читайте дальше.
Привет, Хабр! Меня зовут Евгений Харченко, я член программного комитета DevOpsConf и выступаю на конференциях более пяти лет. Руковожу отделом по развитию практик в разработке и эксплуатации из семи команд инженеров в Райффайзен Банке. Остаюсь в душе инженером, начинал с технической поддержки ServiceDesk, построил внутреннее профессиональное сообщество на 1500 участников.
Это Data-driven статья по мотивам моего доклада на TechLeadConf, статья будет с множеством формул, статистики и информации. Я очень старался вместить много полезного, чтобы вы смогли применить это у себя в командах.
Введение: погружаемся в контекст
У нас больше 3700 сотрудников, распределенных по 262 командам и 14 профессиональным сообществам. Все это — разные сущности, которые плодят артефакты. Мы постоянно вместе работаем над разными проектами и идеями. Это приносит пользу, но и создает определенные сложности.
В 2019 году мы начали развивать инженерные практики в компании, чтобы преодолеть такие проблемы:
Скорость. Темпы разработки не позволяют оперативно адаптироваться к изменениям.
Отсутствие минимально необходимого уровня качества разработки приводит к росту ошибок и дефектов.
Разнообразие подходов и инструментов увеличивает риски дублирования усилий и снижает стандартизацию.
Темпы разработки важны, особенно сейчас, когда множество типовых решений это, условно, общий Boilerplate. И нам тоже это важно. Но когда людей так много, скорость будет отличаться. А еще необходимо избежать создания «велосипедов», которое как раз порождает энтропию и проблемы скорости, взаимодействия, внутренних переходов и ротаций. Ведь стеки и инструменты используют разные.
У нас в компании есть ключевая метрика — Pain Index. Это методология оценки клиентской боли, учитывающая критичность и масштаб проблемы, а также влияние на контакт-центр и другие процессы компании. Метрика формируется из того, как в результате внедрения изменений мы сделали больно нашим клиентам. Причины могут быть разные — как зависящие от нас, так и нет. Разные проблемы имеют разные веса.
Эта метрика представляет определенную цифру — на иллюстрации вы видите показатель в 8,839. Основная задача — работать так, чтобы в конечном счете пользователю было хорошо. Метрика должна стремиться к нулю (в идеале) — то есть, чем меньше, тем лучше.
Чтобы решать проблемы и снижать боли, нужно была свежая инициатива. Ею стала цифровая трансформация в 2019 году. Чтобы ее провести, были нужны:
система управления;
методы и инструменты;
мотивация и дисциплина;
соответствующая инженерная культура в компании.
Мы придумали IT-стандарты внутри компании — лучшие практики разработки и эксплуатации. Их создавали совместно различные группы людей, в том числе, топ-менеджеры.
IT-стандарты поставили в цели Performance Management командам, чтобы они им следовали. В начале важно было задать направление. Цель стандартов — простая: решить все проблемы со скоростью и качеством разработки продуктов, сделать их стабильнее, упростить внутренний найм разработчиков, повысить техническую зрелость.
В качестве IT-стандартов с 2019 по 2021 год мы внедрили семь инженерных практик (сначала — четыре, потом еще три):
Continuous Integration
Auto Tests
Code Review
Trunk Based Development
Continuous Delivery
Logging
Monitoring
Все эти практики реализовывали совместно с инструментами. На тот момент в качестве основных цифровых артефактов, с помощью которых эти практики реализовывались и потом проверялись, был Atlassian Stack:
Bamboo;
Bitbucket;
SonarQube;
Grafana;
GitLab.
Одновременно начинали работу над внутренней платформой разработки. Так выглядела наша первая реализация по сбору и оценке практик и метрик, на devPlatform:
Одни практики проверялись автоматизировано, другие нет.
В результате, с 2019 по 2021 год у нас постоянно росло количество практик и количество команд.
На иллюстрации выше вы видите, что в рамках желтой зоны постоянно росло количество команд, которые реализовывали все практики, ведь за это ставились оценки, и это падало в цели. Измерение цели шло от AA по нисходящей.
Но спустя время, в 2022 году мы перешли от IT-стандартов к лучшим практикам. Причины:
Изменение курса. Приняли решение, что практики должны стать гигиеной, а не частью Performance Management.
Культура. Поставили новый фокус на развитие инженерной культуры.
Изменения и цели. Реализацию практик в командах сделали добровольной, добавление в годовые цели — необязательно.
Состав практик оставался тот же, критерии измерения — тоже. В придачу появилась новая практика Disaster Recovery, и вот как это выглядело теперь:
Trunk Based Development;
Auto Tests;
Code Review;
CI/CD;
Логирование и мониторинг;
Disaster Recovery.
Наша компания начала двигаться к работе над стабильностью, надежностью, устойчивостью.
К концу 2023 — началу 2024 года мы улучшили результаты по Best Practices:
Подсвечу важные инсайты:
Самыми распространенными практиками среди команд стали код-ревью и CI, потому что их проще всего реализовать.
Помимо этого, остался большой блок «Процент неизвестных» — это команды, про которые мы не знаем, реализовывали они инженерные практики или нет. Было много проблем у разных подходов.
Важно отметить, что при этом Pain Index действительно снижался, причем достаточно сильно:
Хотя снижать его тяжело, ведь любое изменение может привести к авариям, проблемам надежности и доступности.
Не только инженерные практики меняют клиентский опыт, но и внешние факторы. Но зато эти изменения внесли большой вклад в технологическое развитие в целом.
В нашей компании в итоге:
У нас есть некое технологическое совершенство:
Engineering Culture — инициатива по внедрению некоторых метрик, практик, SLA Incident Management, legacy-системы, работа со стабильностью и надежностью систем);
лучшие практики;
инженерная культура.
Но в этой статье я сфокусируюсь на инженерных практиках. Цель — показать, что у нас есть и как мы с этим работаем: строим инсайты, собираем статистику и так далее.
У нас есть внутренняя платформа:
В рамках некоторых гипотез мы отслеживаем прогресс, отдельные метрики, критерии успеха. Все это в сумме – огромное количество данных, с которыми мы постоянно непрерывно работаем и которые агрегируем.
В сумме у нас в компании сейчас собирают данные по 82 метрикам десяти инженерных практик. Мы анализируем по разным показателям 1 556 GitLab проектов. Ежедневно проводим 127 592 автоматизированных измерений инженерных практик и их реализации.
Десять инженерных практик
Сейчас у нас есть следующие практики:
Branching;
Code Maintainability;
Code Review;
Integration and Build;
Deployment and Release;
Logging;
Monitoring;
Test Automation;
Code Quality;
InnerSource.
Но в названии доклада упоминаются топ-5 практик — разберем какие и почему. Среди них:
Branching (ветвление);
Integration и Build (интеграция и сборка);
Deployment и Release;
Code Review;
Test Automation.
Мы отследили топ-5 инженерных практик в нашей компании по взаимосвязям, определили, какая практика влияет на другие сильнее всего и с какими критериями успеха это происходит.
Все выводы построены на основе реальных данных:
Наша команда специально выгружала отдельные Excel файлы помимо тех, что есть в системах, чтобы собрать всю информацию.
Есть методологическая база, которую важно проанонсировать и которую вы сможете, если захотите, воспроизвести потом в своей работе. Например, каким образом некая практика влияет на какую-то метрику. В статистическом анализе есть коэффициент корреляции Пирсона. Это статистический метод, который позволяет установить разницу влияния одной величины на другую. С помощью расчетов и преобразований можно понять принцип ее влияния, есть ли линейная зависимость между двумя величинами, влияет ли одна практика на другую.
Попробуем поработать с хит-парадом и посмотрим, что получилось. Чтобы у нас был единый словарь, я расскажу, как мы понимаем каждую практику и дам ее описание.
Branching или практика ветвления
Ветвление — достаточно стандартная практика. Она помогает организовать процесс разработки и управление изменениями в командах, позволяя эффективно координировать работу нескольких разработчиков над общим кодом. Скорее всего, вы знаете эту практику под конкретными реализациями GitFlow, Trunk Based Development, GitHub Flow, GitLab Flow и так далее.
Суть в том, что вы выбираете конкретную реализацию и применяете ее. У вас есть понятные правила игры, определенная модель ветвления. Ее суть — улучшать командное взаимодействие, эффективность, скорость за счет понятных правил процесса разработки, снижать количество конфликтов при слиянии, обеспечивать надежность и контроль кода, ускорять подготовку и выпуск релизов через четкие этапы (release/hotfix), улучшать предсказуемость доставки фич.
Уровни зрелости и измерения практики
С какими измерениями практики мы сталкиваемся ежедневно и как мы вообще ее оцениваем в компании.
Длительность Code Freeze. Проверка факта, что 95% периодов заморозки кода имеют длительность не более порогового значения, у нас это один день. Мы измеряем длительность заморозки изменений в кодовой базе: например, в GitLab.
Наличие Push Rules. Проверка наличия либо отсутствия Push Rules для проекта, либо для его родительских групп. В GitLab есть именование веток Branch Naming Conventions. Определенные модели ветвления уже предопределяют некоторые названия. У нас также есть возможности проверять это в инструментах и CI/CD платформах. Реализовано это среди 76% команд
Срок жизни веток. Сюда входит проверка наличия долгоживущих веток и медианное значение времени их жизни. У нас медианное значение — около 3,6 дней
Размер Merge Requests. Количество измененных строк кода и медианное значение измененных строк кода MR — у нас это 267 строк.
Длительность ревью кода. Медианное значение времени ревью кода у нас — 18 часов. Различные способы ревью влияют на модель ветвления. Если кто-то применяет TBD, то, скорее всего, ревью будет либо очень быстрым, либо флагируется. Мы собираем разный опыт и применяем в компании.
Когда огромное количество айтишников контрибьютят и создают разные артефакты, как понять, что хорошо, что плохо и какие есть бенчмарки? Расскажу про наш метод. Если говорить в целом о показателях в рамках IT в инженерной практике, то успешное выполнение этой практики среди всех ее критериев — 55,8%.
Попробуйте измерить, сколько у вас.
Как реализовать практику или набор «выживальщика»
Любая практика многогранна, ее действительно сложно реализовать. Чтобы понять, с чего начать, я сделал топ-5 шагов, как реализовать практику.
Для ветвления:
Выбираем модель: Trunk-Based или Git-flow (main/develop/feature/release/hotfix).
Настраиваем Push Rules/Branch Naming Convention для стандартизированного именования веток. Скорее всего, они будут продиктованы конкретной моделью ветвления
Минимизируем Code Freeze и автоматизируем управление через CI-Pipeline
Ограничиваем время жизни Feature-веток (< 3 дней) и MR-размер (< 500 стр.) несмотря на то, что вы используете различные модели ветвления.
Понятно, что там, где применяется Git-flow, скорее всего, есть определенные долгоживущие ветки. Это нормально, вы можете поменять их как дефолтные.
Внедряем автоматический Cleanup устаревших веток
Это важно, потому что когда устаревшие ветки копятся, также накапливается количество артефактов, которые могут приводить к ошибкам.
Теперь самое сложное, на мой взгляд.
Эффект от практики
Я рассказывал про коэффициент корреляции Пирсона (влияние одной величины на другую). Практики влияют на метрики, причем как негативно, так и позитивно. Но позитивно с точки зрения не эмоционального окраса, а прироста.
Для примера разберем длительность ревью кода. Как это интерпретировать? В таблице выше указано +0.26. Это значит, что в рамках прогона всех данных среди всех команд по формуле в рамках коэффициента корреляции между величинами, длительность ревью кода увеличивается. Другими словами, чем дольше ревью кода проходит, тем выше вероятность возникновения падений в результате изменений на 26%. Поэтому здесь указано +0.26.
Все эти коэффициенты безразмерны, и чем величина ближе к целому числу, тем влияние выше. В таблице выше мы можем эту связь проследить.
Еще один наглядный факт, чтобы двигаться не как чувствуем, а на основе данных. На примере срока жизни веток — чем дольше живет ветка, то есть, когда показатели практики в ней растут, тем хуже. Когда ветки долго висят, выше вероятность, что вы будете дольше восстанавливаться в результате падения, а потом до деплоймента. Здесь она растет на +0.26, то есть условно на 26%.
Такие инсайты я буду выводить по всем инженерным практикам. Вы сможете их видеть и объяснять, потом возвращаться к презентации, чтобы понять, какие критерии наиболее важны для вас, и потом пробовать применять.
Галочки здесь указывают на здравый смысл, что есть взаимосвязь практики и DORA-метрики, что они действительно коррелируются, нарушений нет.
Ворнинги означают, что есть проблема или аномалия на данных. Например, в примере применение Push Rules на Change Fail +0.10%. Казалось бы, растет практика, мы применяем Push Rules, есть конвенция по именованию веток, а падения растут.
Test Automation или практика автоматизации тестирования
Это очень важная практика. Суть автоматизации тестов — решать проблемы надежности, в том числе, проблемы человеческого фактора, риски, которые могут нести случайные или неконтролируемые изменения. Практика сокращает цикл регресса, убирает затратное ручное «кликание», снижает риск человеческих ошибок и делает проверку качества повторяемой и предсказуемой.
Уровни зрелости и измерения практики
Какие измерения мы делаем в этой практике:
Автоматизированные тесты:
Процент покрытия кода тестами. Проверка, что пайплайны имеют пороговый процент покрытия тестами. У нас процент покрытия — 18% avg.
Наличие Test Job в пайплайнах. Проверка, что пайплайны имеют Job со Stage, отвечающим за тесты за прошедший месяц — наш показатель 60%.
Количество автоматизированных тестов. Проверка количества автоматизированных тестов. Имеем 314 автотестов по сервису на одну команду,
Качество автоматизации тестирования:
Наличие тест-планов. Проверка использования тест-планов. Реализовано среди 15% команд.
Наличие тегов для тестов (разделение на UI, API, E2E..). Проверка разделения тестов на слои. Реализовано у 11% команд.
Процент автоматизированных тестов от общего количества. Проверка доли автоматизированных тестов — у нас 59% avg.
У нас есть инструмент Allure TestOps, с помощью которого мы тоже проверяем проблемы и строим некоторые инсайты на основе этих данных.
Ручные тесты (если они есть):
Количество ручных тестов. Проверка количества ручных тестов. 1 191 ручной тест среди 17% команд.
Напомню, что мы сейчас смотрим на все критерии. Вы можете их выстраивать по уровням зрелости (от 1 до 5), по росту сложности и так далее.
Практика в компании выполнена успешно среди всех команд — показатели 19%, но это первый инженерный опыт и начало пути.
Как можно реализовать. Набор «выживальщика»
Выделяем слои: unit → integration → E2E.
Идея проста. Кто-то помнит пирамиду тестирования, кто-то — интеграционные юниты, E2E. Нам важно различным способом строить подходы и организовывать процесс.
Пишем тесты и добавляем job в pipeline для каждого уровня.
Настраиваем отчеты покрытия через Allure/SonarQube.
Внедряем gate на минимальное покрытие (например, ≥70%) и блокировку MR при фейле.
Автоматически обновляем окружения и чистим устаревшие тест-артефакты, если они есть.
Эффект от практики
Самая интересная часть, на мой взгляд.
Ручные тесты достаточно сильно влияют на все остальное. Если они появляются, то вероятность, что в результате внедрения изменений что-то упадет, снижается примерно на 20%.
Test Job в пайплайнах ещё сильнее снижает вероятность возникновения проблем при внедрении изменений.
Теги — это продвинутый механизм тегирования. Если присутствуют теги тестов, например, кто-то использует Allure TestOps, заходит в продвинутые стратегии реализации тестирования, это еще сильнее снижает падения.
Еще одна важная история — если есть тест-планы, то в сумме будет выше скорость работы.
Метрика Change Lead Time свидетельствует о том, как мы быстро внедряем изменения.
Fail Deployment Recovery Time: если Test Job в пайплайнах есть, то выше вероятность, что в результате падения пайплайны будут быстрее восстанавливаться. Если эта метрика — 0.33, то мы сокращаем это время на 33%.
С точки зрения здравого смысла все хорошо. Единственное — Change Fail % — незначительная доля автоматизированных тестов (сотая), поэтому можно сказать, что это либо погрешность, либо особо не заострять на этом внимание. Но факт есть факт, это немного увеличивает падение, хотя и гарантирует стабильность. Вот такое противоречие.
Integration and Build или практика интеграции и сборки
Под интеграцией и сборкой мы понимаем процесс, с помощью которого команда может взаимодействовать и быстрее интегрировать изменения. Эту практику все знают как Continuous Integration.
Проблема в том, что если углубиться в практику и терминологию, не сразу все становится Continuous. Сначала придется вручную собирать, постепенно внедрять и приходить к процессам Cintinious. Практика решает проблемы коммуникации в команде, интеграции изменений, качества и стабильности выпусков.
Уровни зрелости и измерения практики
Как вы видели в ветвлении и в автоматизации тестирования, приходится углубиться в другие области по критериям измерений. Поэтому в интеграции сборки на первых уровнях зрелости выделяем всего два ключевых критерия:
Наличие интеграций/пайплайнов и их количество. Сюда входит проверка количества пайплайнов за прошедший месяц, то есть ритма разработки, когда постоянно что-то запускается, выполняется, изменяется. Среднее число пайплайнов в месяц — 29.
Наличие сборок и их количество. Проверка, что пайплайны имеют stage или job с именованием build/package за прошедший месяц. Пайплайн с этапом сборки (build/package) — 55% avg.
Мы расширяем критерии, если появляются новые опыты внедрения. Это живой процесс.
У нас 39% реализации практики среди всех команд. И 39% — не значит, что всё плохо. Это значит, что в сумме по уровню требований есть перформеры, и есть те, кто чуть менее интенсивно выполняет эту практику. Но, так или иначе, сборки постоянно есть у всех.
Как можно реализовать. Набор «выживальщика»
Настроить CI-пайплайн с этапами build/test/code-scan. Эти этапы мы уже обозревали.
Добавить Job Build/Package и автотесты.
Подключить Quality Gates (SonarQube, линтеры). Quality Gates также нужны и на предыдущих шагах для интеграции.
Внедрить версионирование сборок через специальный job version. На мой взгляд, такие инструменты, как семантическое версионирование, Git Version помогают лучше всего. Мы их тоже применяем.
Автоматизировать шаги пайплайна, направленные на интеграцию, потому что у каждого они могут быть своими.
Эффекты от практики
У практики есть главный эффект. Хотя интеграция и сборка действительно важны, все в это верят и понимают. Но, если смотреть с точки зрения данных, корреляция не так уж и сильна.
Количество пайплайнов влияет на Fail Deployment Recovery Time. То есть, они снижают время восстановления. Чем чаще они происходят, тем, скорее всего, быстрее вы будете восстанавливаться.
В целом среди всех показателей здравый смысл присутствует. Единственное «но» — количество пайплайнов может приводить к более высокому падению в результате изменений в редких случаях (0,01).
Deployment and Release. Практика развертывания и релиза
Практика развертывания и выпуска релиза помогает командам разработки организовать и ускорить процесс поставки изменений для пользователей. Эта классная практика у нас в компании тоже реализуется и мы ее измеряем. Считаю ее самой важной, поскольку она действительно сильно влияет. Вы увидите это наглядно на показателях.
Мы понимаем практику Deployment and Release как процесс поставки ценностей клиенту. С ее помощью можно ускоряться и решать проблемы с воспроизводимостью и стабильностью релизов. Также она улучшает метрики эффективности, таким образом, ускоряет скорость восстановления и частоту внедряемых изменений. В целом, если практика реализована On-Demand Deploy, можно чаще сливаться по требованию. Она дает гарантии консистентности окружений и простой отмены релиза при сбоях, улучшает DORA-метрик.
Уровни зрелости и измерения практики
Мы выделяем несколько уровней зрелости практики:
Качество развертываний:
Тип развертывания — ручной или авто для test-/preview-/production-среды.
Проверка типа развертывания (manual/auto).
Частота развертываний:
Проверка количества развертываний на test-/preview-/production-среды. У нас среднее количество развертываний в месяц — dev=17, test=18, prod=4.
Проверка количества деплоев за последний месяц для среды.
Мы смотрим не только деплойменты, но и релизы, которые отличаются. Под релизом я понимаю конкретные терминологии GitLab — возможность срезать теги, создавать релизы, с помощью которых формируются слепки, неизменяемая кодовая база, которые можно впоследствии раскатывать. Можно просто деплоиться и не делать релиз. Это разные вещи.
Частота релизов:
Проверка частоты релизов за последний месяц.
Качество релизов:
Проверка заполнения описания релиза (Release Notes). У нас медианное количество символов для описания релиза — 475.
Качество и варианты окружений:
Проверка наличия сред test/preview/prod.
Проверка среды на устаревание (проверка даты последнего развертывания на среду). Процент команд, имеющих неустаревшие среды на production — 33%. Это среды, на которые не менее месяца назад были развертывания.
Проверка состояния среды (что среда доступна после изменений). Доступность сред у нас — 100%, это когда state = available. Мы проверяем, есть ли устаревшие среды у команд, которые они развернули и ничего не делали с ними некоторое время, или в которые больше не проходит деплой, они зависают и висят в воздухе.
Успешное выполнение практики среди команд у нас составляет 48%. Среднее количество окружений GitLab Environment — 5. Обращу внимание на важный фактор — это доступность сред. Все доходят до продакшена со 100% успешностью в результате изменений. Спустя длительное время, конечно, могут происходить аварии, это неизбежно, но в сумме, когда происходят изменения, среды доступны.
Как можно реализовать. Набор «выживальщика»
Соблюдаем базу до деплоя: Code Review/Branching/Integration & Build. Выполняем предыдущие шаги: собери, протестируй, дойди до этапа.
Определяем три уровня окружений: test, preview, production.
Конечно, вы сами можете решать, сколько окружений нужно. Но мне кажется, что, как минимум, необходимы test, preview и production, чтобы доходить и поставлять ценности прогнозируемо, иметь воспроизводимость, насколько это вообще возможно.
3. Конфигурируем GitLab Pipelines с job’ами для каждого этапа (deploy, smoke tests, rollback).
4. Автоматизируем управление релизами/версиями и стратегиями деплоя (canary, blue-green).
К процессу можно подходить по-разному. Мы чаще всего реализуем простые Rolling Updates изменения. У нашей команды, по сути, происходит dev-to-dev.
5. Автоматически создаем/удаляем динамические окружения при параллельной разработке.
Эффект от практики
Качество и количество деплоев на продакшен действительно влияет на частоту изменений. Есть достаточно сильная связь — чаще деплоишь, частота выше. Все понятно и линейно. То же самое касается частоты релизов и устаревания сред. Интересно, что если сред, на которые не деплоились последние 30 дней — меньше, то и частота деплоя ниже. И корреляция тоже будет выше, поэтому не стоит забрасывать этот показатель.
Еще есть метрика Change Lead Time. Мы понимаем, что когда чаще деплоимся, нарабатываем качество, а скорость становится выше. В результате мы эффективнее, а доступность всех сред тоже растет.
Failed Deployment Recovery Time: чем чаще релизитесь, тем быстрее будете восстанавливаться после падения.
Здравый смысл есть во всех этих тезисах за исключением проверки количества сред. С одной стороны, данная корреляция говорит о том, что если количество сред больше, то и вероятность падения выше. В результате ты проходишь разные этапы, где-то что-то может пойти не так, происходит падение. Но, с другой стороны, всё должно стать надежнее. В общем, как показывает опыт, практики — это определенные эксперименты, с которыми нужно жить.
Code Review. Практика ревью кода
В этой практике тоже есть интересные показатели, инсайты и критерии.
Практика ревью кода помогает командам разработки повышать качество кода и улучшать взаимодействие и коммуникацию благодаря обратной связи по изменениям.
Ревью выявляет и устраняет дефекты кода до продакшна, усиливает командное взаимодействие и обмен знаниями, стандартизирует подход (DoD, Coding Сonventions), повышает инженерную культуру и общее качество кода, решает проблемы коммуникации. Практика также показывает хорошие результаты в цифровых значениях.
Уровни зрелости и измерения практики
Какие измерения мы проводим в этой практике:
Длительность ревью кода:
Время реакции на открытый Merge Request.
Медианное значение времени реакции до начала код-ревью для Merge Request — у нас среднее значение около 13 часов.
Длительность ревью кода. Медианное значение длительности ревью кода для Merge Request — у нас среднее значение около 18 часов.
Мы смотрим на длительность ревью-кода в двух разрезах: сумма на все ревью и скорость реакции на созданный Merge Request. Так мы проверяем время реакции.
Оформление Merge Request:
Размер Merge Request — в среднем 267 строк.
Медианное количество измененных строк кода среди всех MR проекта.
Связь с JIRA-задачей — у нас показатель 99% команд.
Проверка заголовка или описания MR на содержание ссылки на тикет в JIRA — у 99% команд.
Наличие CI/CD Pipeline при Merge Request.
Проверка наличия Pipeline на каждый MR.
Описание Merge Request — в среднем 17 символов.
Медианное значение среди описания всех MR проекта.
Так в описании Merge Request автор оставляет собственные мысли и идеи о том, что и как он реализует.
Активность в Merge Request:
Количество комментариев.
Проверка количества комментариев в MR на 95 перцентили.
Количество ревьюеров. Проверка количества ревьюеров в MR на 95 перцентили. В среднем у нас их два.
Наличие нотификаций. Наличие нотификаций с помощью интеграции GitLab с Mattermost — у 24% команд.
Количество коммитов. Проверка количества коммитов в MR на 95 перцентили. Всего у нас в среднем семь коммитов в MR.
Количество аппруверов. Проверка количества аппруверов в MR на 95 перцентили. В среднем у нас два аппрувера в MR.
Мы смотрим, есть ли комментарии, аппруверы, ревьюеры, нотификации, количество коммитов, которые прилетают на Merge Request, и с какими показателями это выполняется. В сумме можно сказать, что практика по многочисленным критериям выполняется 46,5% — это показатель для идеального выполнения.
Как можно реализовать. Набор «выживальщика»
Определить стандарт ревью (DoD, MR Templates, критерии)
и включить в процесс разработки.Внедрить MR-пайплайн в GitLab CI:
Linters → SonarQube → Quality Gates → Unit/Integration Checks.Настроить обязательные поля MR: описание, ссылка на JIRA, чек-лист.
Обеспечить минимум 1–2 ревьюера и 1 аппрувера (по возможности);
настроить нотификации в корпоративный мессенджер,Мониторить метрики MR в реальном времени через GitLab API
(см. блок «Как измеряем») и принимать управленческие решения для улучшений.
В GitLab, например, есть Default Merge Request Templates, с помощью которых при создании можно подтягивать конкретные шаблоны, настраивать обязательные поля, обеспечить ревьюеров. Если вы хотите управлять, то точно рекомендую измерять практику, чтобы контролировать это.
Эффект от практики
Эффект действительно есть, она сокращает длительность ревью кода и частоту деплоев. Чем длительность ревью кода ниже, тем мы быстрее и чаще деплоимся.
Практика снижает время реакции. Чем дольше мы реагируем на Merge Request, тем выше вероятность, что это приведет к падениям в результате внедрения изменений выше. Это видно в значениях еще двух показателей:
Количество коммитов. Например, Merge Request открыт, в него коммитят снова и снова. Наш опыт показывает, что это чаще приводит к падениям в результате внедрения изменений.
Размер Merge Request. Чем больше размер MR, тем выше вероятность падений.
Здравый смысл везде в порядке, за исключением размера Merge Request. Хотя корреляция небольшая, всего 0,05.
После практик
Мы рассмотрели пять инженерных практик и как они реализуются. Теперь обсудим эффекты в совокупности.
Стоит ли внедрять инженерные практики?
Зачем вообще этим заниматься?
Какой эффект от внедрения?
Расскажу, что и кому можно с этим делать.
Эффект от инженерных практик
Эффект от инженерных практик действительно присутствует.
Code Review влияет на частоту деплоев, значительно повышает частоту релизов, особенно если с этим работать быстро и качественно.
Deployment and release тоже увеличивают частоту деплоев. Могу сказать, что практика сильно влияет и стоит взять её в работу.
Практика ветвления ускоряет Failed Deployment Recovery Time. Если вы ветвитесь соответствующим образом, у вас есть Branch Name Convention и ряд показателей, которые вы применяете, то вы будете быстрее восстанавливаться.
Мы разбирали это на основе данных, я анализировал цифры нашей компании. Но не только я один это делал. Есть DORA Core модель, которую я часто упоминаю.
Схематично суть этой модели такая:
У нас есть определенные Capabilities — это инженерные практики, то есть потоки: то, как мы выполняем код ревью, как что-то реализуем. Они предопределяют эффективность, которую мы измеряем в DORA метриках (и в модели это измеряется). Соответственно, наша эффективность предопределяет коммерческий успех.
Но стоит оговориться, что еще существует множество других условий, внешний мир, реальность, которая тоже влияет на нашу эффективность и коммерческий успех компании. Но мы, как инженеры, можем влиять со своей стороны, и это важно. Поэтому я рекомендую в этом разобраться.
Оценка инженерных практик
Мы оцениваем команды, смотрим на реализацию всех критериев в совокупности на основе кластерного анализа.
Кластерный анализ — это метод принятия решений, работающий с любой выборкой, огромным количеством значений. Мы берем все значения по всем практикам и кластеризуем их. В своих исследованиях в работе мы используем тот же метод, что и DORA. Строим определенные уровни перформанса и выделяем 4 октета (high, medium, low, elite).
В примере ниже — длительность ревью кода:
Например, elite уровень у нас от 1 до 46 минут. Мы берем за целевой уровень high и ставим его как бенчмарк. Делаем мы это не один раз. Эта модель постоянно прогоняется, применяется под разными экспериментами. Чем больше данных, тем более они объективны.
Поэтому все практики носят исследовательский характер. Я часто в своей работе смотрю, всегда ли хорошо большее количество сред у команд. Однозначных ответов нет, но важны причинно-следственные связи. Советую в это погружаться, если вы, как и наша команда, работаете над совершенствованием этих практик.
Синергия практик. Все практики вместе – больше, чем их сумма
Если внедрять каждую практику по отдельности, это даст меньше эффекта, чем сумма всех. Проблема в том, что каждый единичный коэффициент коррелирует по-своему, а на масштабе бьет сильнее и выше.
Самое сильное влияние — на Change Fail %. Это видно в цифре 0,42. Остальные тоже влияют, но меньше. Все практики вместе делают нас устойчивее к изменениям и позволяют быстрее восстанавливаться.
Выводы и советы. Как начать внедрять инженерные практики
Предлагаю свой вариант Roadmap для внедрения инженерных практик:
1 шаг. Нужно понять текущее состояние и начинать собирать информацию. Это можно делать вручную, на сбор уйдет определенное время — это нормально.
2 шаг. Внедряем фундамент в виде автоматизации CI/CD, вводим обязательный процесс код-ревью, внедряем процессы тестирования, сборки, Quality Gates.
3 шаг. Постепенно подкручиваем процесс управления качеством и в сумме замыкаем цикл улучшений.
4 шаг. Делаем процесс поставки, заходим еще на один круг.
Это был Roadmap, но есть еще и порядок внедрения инженерных практик:
Я решил организовать практики в таком порядке. Мы посмотрели на связь с командой, показатели и поняли, что лучше начинать с упорядочивания кодовой базы, поработать над ветвлением, после этого ставить на поток CI, внедрять культуру код-ревью, автоматизировать эти изменения. В завершение — переходить к измерениям и внедрять поставку. Но это можно делать и непрерывно, все зависит от условий и команды, в которых вы находитесь.
Разница между roadmap и порядком внедрения:
Порядок внедрения задает технические зависимости: что должно быть готово до, что после, и какая у них иерархия.
Roadmap группирует и календаризирует эти шаги, позволяя запускать некоторые инициативы одновременно для ускорения эффекта.
Что и кому со всем этим делать?
Если вы Junior/Middle, я бы предложил начать разбираться в инженерных практиках. Это действительно важно. Перенимайте опыт более опытных коллег, изучайте отраслевые практики.
Если вы Senior/Lead, работаете уже давно, у вас есть опыт, внедряйте практики осознанно. Это точно стоит своего времени. А еще делитесь знаниями с коллегами.
Если вы EM/CTO, то попробуйте внедрять инженерные практики в технологическую стратегию компании. Мы делаем именно так, ставим это в цели и показатели, заходим на непрерывный цикл улучшений, прописываем в технологическую стратегию технического совершенства.
Заключение
Инженерная культура и технические практики взаимосвязаны — потоки, информация, коммуникация, взаимодействие. Используйте две области. То, как команда работает, действительно пересекается с инженерными практиками. У нас есть инсайты и выводы, что это действительно работает.
Инженерные практики влияют на эффективность работы команды и компании, поэтому важно их измерять. Это можно увидеть с помощью DORA-метрик эффективности.
Все данные в разработке и эксплуатации дают возможность принимать объективные управленческие решения!
Для чего нужны в конечном счете все эти цифры, данные, показатели? Они дают возможность принятия хоть сколько-нибудь объективных управленческих решений.
Скрытый текст
А чтобы разобраться, как принимать управленческие и технологические решения глубже — приходите на TechLead Conf. Познакомьтесь с лучшими практиками управления и важными инсайтами, узнайте, как принимают решения гиганты отрасли и их технические лидеры.