Site icon Лофт Николая Сарры

Agile метрики. Часть 5: Метрики из инструментов CI/CD

В предыдущих частях мы рассмотрели: метрики из Agile Project Tools, метрики Lean Kanban, метрики из инструментов систем контроля версий. В этой статье мы рассмотрим agile метрики из инструментов CI/CD.

Эти метрики берутся из инструментов непрерывной интеграции и непрерывной доставки. В настоящее время они являются частью целостной цепочки инструментов DevOps и автоматизированного конвейера.

Покрытие тестами

Это очень популярный и неоднозначный показатель, на котором застревают многие. Это доля кодовой базы, которая покрывается автоматизированными тестами. В частности, это доля методов, для которых определены один или несколько автоматических тестов (модульных или интеграционных). Хотя покрытие автоматическими тестами – хорошая идея, вы должны быть осторожны с этой метрикой. Есть несколько причин по которым к этому показателю следует относиться с осторожностью:

Высокий показатель покрытия тестами – не всегда хорошо. Если вы уделяете этому много внимания и заставляете разработчиков увеличивать этот показатель, вы можете стать причиной проведения бесполезных тестов для улучшения показателя. Это плохо, во-первых потому, что вы получаете не реалистичное представление о реальном покрытии тестами, а во-вторых эта практика начинает удручать разработчиков.

Это не означает, что вам не нужно заботиться об автоматизации тестирования. Важно помнить, что покрытие тестами – сложная и тонкая вещь, которую нельзя выразить числом. Это число может быть частью серии регулярных разговоров, подкрепленных множеством точек контроля данных и регулярными проверками кода.

Краткое замечание: эту метрику фактически можно получить без использования инструментов CI/CD, поскольку ее можно получить из системы управления версиями (в некоторых это штатная возможность, для других существуют плагины, которые могут ее вычислить). Я поместил ее в этом разделе, так как она концептуально связана с другими метриками CI/CD.

Хорошие и неудачные сборки

Данный показатель это процент ошибочных сборок от общего количества. Это значение должно быть небольшим, в идеале очень низким. Разработчики должны выполнять сборки на своих машинах (которые должны иметь регулярно обновляемую кодовую базу), прежде чем что-либо проверять. Если данный показатель больше 5%, это плохой знак.

Сбежавшие дефекты

Это количество дефектов, которые были обнаружены только после выпуска релиза. Этот показатель немногим похож на “Количество возникших инцидентов” (о нем мы поговорим в разделе “Управление услугами” далее), но не совсем. Дефект может попасть в релиз, но никогда не будет рассматриваться как инцидент (он может не влиять на клиентский опыт, но все равно остается дефектом). Также инцидент может возникать и при отсутствии дефектов. Дефект – это проблема в кодовой базе. Количество ускользающих дефектов должно быть нулевым или стремиться к этому значению.

Неудачные развертывания

Это просто количество неудачных развертываний. Вы можете подсчитывать этот показатель за неделю, месяц или год, в зависимости от того как часто вы выпускаете релизы. Развертывание может завершиться неудачей по ряду причин, зачастую из-за ошибок в конфигурации инструмента развертывания. Вы можете учитывать этот показатель только для производственной (production) среды или можете включить другие среды, такие как промежуточная (staging) или тестовая (test). Это значение должно быть равно нулю или максимально близким, особенно для производственной среды. Вы должны без проблем получать это число из вашего DevOps инструмента.

Среднее время между выпусками

Данная метрика – средний промежуток времени между выпусками релизов. Этот показатель кажется простым, но необходимо помнить о следующем:

Как использовать эту метрику

Эта метрика очень проста: берете количество развертываний за определенный период времени (например, три месяца) и делите его на количество временных промежутков (например количество рабочих дней в трех месяцах). Это будет ваше среднее время между выпусками. Вы можете брать любой промежуток времени, но придерживайтесь следующих рекомендаций:

Количество измененных строк кода (CLOC) на выпуск

Данный показатель измеряет среднее количество измененных строк кода в выпуске. Измененная строка означает, что было: удаление, добавление или изменение. Таким образом чтобы вычислить этот показатель, вы разделите общее количество измененных строк кода за выбранный временной промежуток на количество релизов выпущенных за этот период. Это может показаться нелогичным, но нужно стремиться чтобы этот показатель был небольшим и становился меньше. Это связано с тем, что в небольших релизах меньше изменений, меньше сложности и меньше рисков. Много небольших релизов лучше малого количества больших.

Продолжение

В следующей части мы рассмотрим метрики относящиеся к бизнес-аналитике.

Exit mobile version