SonarQube Техническое управление долгом с помощью Quality Gate

Question

При настройке пользовательских стробов качества, по умолчанию SonarQube Way был выбран в качестве исходного эталона, а затем откорректирован и настроен (добавлены дополнительные проверки). Наши текущие качественные ворота выглядят следующим образом (старая версия против текущей версии):

Blocker issues:             error threshold at 0
Complexity/class:           error threshold at 12
Complexity/file:            error threshold at 12
Complexity/function         error threshold at 2
Coverage                    error threshold at 100 >> changed to 65
Critical issues             error threshold at 0
Duplicated lines (%)        error threshold at 5
Info issues                 error threshold at 10
Major issues                error threshold at 50
Minor issues                error threshold at 100
Overall coverage            error threshold at 100 >> changed to 65
Public documented API (%)   error threshold at 50
Skipped Unit tests          error threshold at 0
Technical Debts             error threshold at 10d >> change to (?? < 10)
Unit test errors            error threshold at 0
Unit test failures          error threshold at 0

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

Тем не менее, общие ворота качества должны как-то (математически?) Следовать определенной пропорции.

Вопрос: как рассчитать наиболее подходящий порог технического долга с учетом приведенных выше ослаблений?

Из старой статьи (2009, следовательно, скорее всего, больше не применимо) была выведена следующая формула:

TechDebt = (cost_to_fix_one_block * duplicated_blocks) + \
     (cost_to fix_one_violation * mandatory_violations) + \
     (cost_to_comment_one_API * public_undocumented_api) + \
     (cost_to_cover_one_of_complexity * uncovered_complexity_by_tests) + \
     (cost_to_split_a_method * function_complexity_distribution) + \
     (cost_to_split_a_class * class_complexity_distribution)

Замечания: \ добавлено для удобства чтения

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

Другие более поздние источники подробно объясняют связанные пункты, но не как корректировать значения пропорционально.

sonar.technicalDebt.developmentCost (Admin / Configuration / Technical Debt) имеет значение по умолчанию 30 минут, что означает 1 LOC (стоимость разработки 1 строки кода) = 30, но все еще не на уровне детализации переменных выше, и не полезно в этом случае.

Answer 1

Качественные Ворота состоят из набора условий. Ваш список условий намного длиннее, чем в списке качества по умолчанию. Большинство условий, которые вы перечисляете, не находятся в пределе качества по умолчанию. Вместо этого он выглядит так, как будто вы отредактировали пороговые значения по умолчанию для ряда правил.

И в некотором смысле, вы говорите о яблоках и апельсинах.

Порог технического долга может быть включен в Quality Gate, но по умолчанию это не так. Вместо этого Технический коэффициент задолженности по новому коду включен в QG по умолчанию. Но концепция технического долга имеет отношение к вашему вопросу. Если вы установили жесткий порог для технического долга в качестве качества, для небольших проектов будет легче пройти QG, чем для крупных проектов. Если вместо этого вы используете Технический коэффициент долга или Технический коэффициент долга для нового кода (рекомендуется), тогда вы устанавливаете свой критерий качества на основе соотношения размера базы кода и технического долга. Таким образом, каждый проект имеет одинаковые шансы на успех или провал. Формула такая:

Стоимость восстановления / (Стоимость разработки 1 строки кода * Количество строк кода)

с, ориентировочная стоимость разработки линии 30 мин. Это значение доступно для редактирования, кстати: Администрирование> Технический долг> Стоимость разработки

Стандартные показатели качества включают в себя пороговое значение ошибки технического долга по новому коду, равное 5.