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

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

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

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

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

• он не различает хорошие и плохие тесты;
• это не мешает разработчикам писать совершенно бесполезные тесты (просто подтверждая истину или что-то еще тестом);
• он не охватывает все сквозные тесты, поскольку они тестируют не метод, а точки входа и компоненты пользовательского интерфейса системы.

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

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

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

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

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

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

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

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

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

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

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

• нужно учитывать только развертку в производственной среде. Промежуточная и тестовые среды не идут в счет. Это связано с тем, что развертывания в тестовой среде происходят достаточно часто (несколько раз в день);
• считаются только успешные развертывания;
• выпуск не обязательно должен быть для клиентов; это может быть сине-зеленое развертывание, пилотная группа или включение/отключение функционала и т.п., но это все равно будет успешное развертывание. Решение о выпуске для клиента – это совсем другое решение (и чаще всего бизнес-решение, а не техническое).

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

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

• чем больше временной диапазон, тем лучше для выборки. Три месяца – хорошая отправная точка, но вы можете изменить его, если это имеет смысл;
• используйте скользящий диапазон времени: например берите не за три месяца в общем, а возьмите среднее значение за каждый месяц из последних трех;
• не меняйте в произвольном порядке размер временной выборки, для улучшений или ухудшения статистики. Будьте честны и прозрачны.

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

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

Продолжение

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