Quality Gates

• Introduction
• Visite vidéo
• Quality gates et échec de build
• Créer et personnaliser des quality gates
• Explorer le statut des quality gates
• Prioriser les corrections de problèmes et la métrique Breaking-Point

Un Quality Gate est une vérification sur un fait de qualité du code qui doit être avant la livraison et éventuellement avant le commit dans le gestionnaire de sources. Un Quality Gate peut être vu comme une mesure PASS/FAIL de la qualité logicielle.

CppDepend propose une douzaine de Quality Gates par défaut liés à des mesures comme le montant de dette technique, la couverture de code ou le nombre de problèmes d’une gravité donnée.

Notez que des éléments spéciaux icônes losange rouge / jaune / vert affiche le statut des quality gates : échec / avertissement / succès.

Les Quality Gates peuvent servir à faire échouer le build quand certains critères ne sont pas vérifiés.

Quand au moins un quality gate échoue, CppDepend.Console.exe renvoie une valeur non nulle pouvant faire échouer le build.

Ce qui rend CppDepend unique : un Quality Gate est une requête C# LINQ facile à créer, éditer et personnaliser. Par exemple, pour imposer un certain taux de couverture via un Quality Gate, écrivez simplement :

1// <QualityGate Name="Percentage Code Coverage" Unit="%" />
2
3failif value < 70%
4
5warnif value < 80%
6
7codeBase.PercentageCoverage

Notez aussi les clauses spéciales failif (clause obligatoire) et warnif (clause optionnelle) qui sont spécifiques à CQLinq de CppDepend. codebase.PercentageCoverage est en fait une instruction C# que CppDepend évalue.

Remarquez le commentaire d'en-tête spécial qui définit le nom et l'unité du Quality Gate. L'unité ici est la chaîne "%". Elle peut être éventuellement répétée après les seuils pour des raisons de lisibilité.

Un Quality Gate peut également déterminer une mesure basée sur le diff depuis la baseline. Par exemple, le Quality Gate ci-dessous garantit que la dette technique globale ne dépasse pas certains seuils depuis la baseline.

Notez qu’un tag peut servir à décrire le Quality Gate pour les non-développeurs.

1// <QualityGate Name="New Debt since Baseline" Unit="man-days" />
2
3failif value > 2 man-days
4
5warnif value > 0 man-days
6
7let debt = Issues.Sum(i => i.Debt)
8
9let debtInBaseline = IssuesInBaseline.Sum(i => i.Debt)
10
11select (debt - debtInBaseline).ToManDay()
12
13//<Description>
14
15// This Quality Gate fails if the estimated effort to fix new or worsened
16
17// issues (what is called the *New Debt since Baseline*) is higher
18
19// than 2 man-days.
20
21//
22
23// This Quality Gate warns if this estimated effort is positive.
24
25//
26
27// Debt documentation: http://www.CppDepend.com/docs/technical-debt#Debt
28
29//</Description>

Notez enfin que lors de la définition d'un seuil de Quality Gate, le mot-clé valeur doit être remplacé par le mot-clé count si la requête LINQ renvoie des lignes au lieu d'un scalaire.

Ceci est utile pour rendre le résultat du Quality Gate plus informatif lorsque cela a du sens.

L'ensemble des statuts des Quality Gates est interrogeable via des requêtes LINQ C#.

Le Dashboard résume le statut des Quality Gates. Un simple clic génère une requête LINQ qui affiche le statut détaillé de chaque Quality Gate. Les statuts des Quality Gates sont également fournis dans le rapport HTML+js.

Le Point de rupture d'un problème ou d'un ensemble de problèmes, est le point dans le temps à partir duquel le coût estimé pour corriger le(s) problème(s) atteindra le coût estimé pour laisser le(s) problème(s) non corrigé(s).

Le point de rupture est le dette divisée par l’intérêt annuel. Par exemple, si le coût estimé pour rembourser la dette est de 10 jours-homme et que l'intérêt annuel estimé est de 2 jours-homme par an, alors le point de rupture est égal à 5 ans à partir de maintenant.

Notez qu’un point de rupture qui est inférieur à par an signifie que, durant les 12 prochains mois, il est estimé qu'il serait moins coûteux de corriger la dette que de ne pas la corriger.

Notez également qu'un point de rupture n'est pas mesuré en temps-homme comme la dette ou l'intérêt annuel (un mois-homme ou une année-homme), mais plutôt en durée régulière (mois ou années). Les valeurs de point de rupture sont typées avec TimeSpan.

Quand il s’agit de prioriser les problèmes à corriger en premier, la sévérité du problème est un paramètre important. Pour rappel : la sévérité est la mesure discrète de l'intérêt annuel. Par conséquent, plus l'intérêt annuel est élevé, plus il est important de corriger.

Cependant, pour un niveau de sévérité donné, tous les problèmes ne sont pas égaux. Certains demanderont plus d'efforts à corriger. Cela est estimé via la mesure de la dette technique. Par conséquent, pour estimer le Retour sur investissement (ROI) d'une correction de problème, il est logique d'estimer la dette divisée par l'intérêt annuel. Cette estimation est le point de rupture pour lequel plus la valeur est faible, plus le ROI est élevé.

Précisons que dans l'ensemble des règles par défaut, les problèmes relatifs à de nouveaux problèmes depuis la baseline, comme changements cassants d’API, qualité des éléments de code qui se dégrade encore, nouveaux éléments de code non testés... sont des problèmes qui produisent un intérêt annuel plus élevé, et donc une sévérité plus élevée que les autres problèmes. Cela est conforme à la bonne pratique consistant à corriger d'abord les problèmes récemment introduits.