Ce que j’ai appris à me construire des outils PowerShell partie1 : La cueillette de métriques

Parlons de qualité de code

L’intégration continue (CI) d’application typique est un sujet chaud depuis plusieurs années maintenant, et une panoplie d’exemples sont disponibles pour vous aider à y parvenir. Mais qu’en est-il d’appliquer cette même discipline afin d’assurer le même niveau de qualité à vos scripts PowerShell ?

Nous avons tous passé par ce même chemin de croix avec PowerShell. Au début, il s’agit de quelques fonctions utilitaires dans un script permettant d’automatiser des tâches fastidieuses et répétitives. En cours de route, le script devient de plus en plus gros et est finalement séparé en plusieurs unités logiques. Éventuellement, ces unités se retrouvent sous un gestionnaire de source. Elles sont organisées dans un module qui peut être déployé à titre de boîte à outils aidant les SysAdmin et DevOps de votre organisation. Cette situation vous est familière ? Elle l’est pour ma part !

Le scénario ci-dessus est parfait jusqu’à ce que de la maintenance soit requise et qu’une nouvelle version de l’outil doit être déployée. Comment prouver que l’outil fonctionne toujours correctement ? Que le code source répond toujours aux standards de l’organisation et à ses règles d’affaires ? À l’aide de bonnes vieilles métriques automatisées qui peuvent être utilisées pour bâtir des tableaux de bord (j’adore les tableaux de bord) !

Cet article est le premier de deux. Le premier couvrira la collecte de métriques via des tests et de l’analyse de code. Le deuxième visera à complètement automatiser ce processus en utilisant VSTS.

Pour cet article, j’ai créé un module tout simple. Malgré le fait que nous ne plongerons pas en profondeur dans le code, jetons un coup d’œil à l’anatomie du module. Je ne tente pas de réinventer la roue, il s’agit simplement d’un support visuel.

1. Le code source contenant la logique et la définition du module
2. La suite de tests incluant des données de tests pour certaines fonctionnalités
3. Des scripts utilitaires pour VSTS qui seront couverts dans le prochain article de cette série

Qui plus est, nous allons tirer avantage de deux de mes modules PowerShell préférés disponibles sur PowerShellGallery: Pester comme engin de test et PSScriptAnalyser pour l’analyse du code

Ouvrez une console PowerShell en tant qu’Administrateur et exécutez les commandes suivantes :

Install-Module -Name Pester -Scope CurrentUser -Force -AllowClobber Install-Module -Name PSScriptAnalyzer -Scope CurrentUser -Force -AllowClobber

Métrique #1 – Tests brisés

L’écriture de tests sert principalement à prouver que votre système ne présente pas de défaillance et, en mon sens, il s’agit du niveau de documentation le plus bas d’un système. Un collègue et bon ami à moi m’a un jour dit ces sages paroles : « Du code en production sans tests, c’est déjà du code legacy ! »

Exécuter la commande suivante à la racine du module.

Invoke-Pester -OutputFormat NUnitXml -OutputFile ".\Tests\logs\Test-Pester.XML"

Il en résultera la capture d’écran suivante comprenant des tests brisés (tel que souhaité). En journalisant chacune des exécutions dans un fichier, nous nous assurons de remonter les problèmes.

Métrique #2 – Couverture de code

La deuxième métrique est un bon indicateur du degré de test appliqué au système. Ce qui se traduit par une haute couverture de code (en pourcentage) est un indicateur de faible chance d’avoir des défectuosités cachées dans votre module. Elle peut être considérée comme un facteur de sécurité plus qu’autre chose. Puisqu’elle vient gratuitement avec Pester, prenons-en avantage !

En ajoutant des paramètres supplémentaires à la cmdlet Invoke-Pester, nous pouvons faire la cueillette de deux métriques distinctes en une seule commande. Habile, mais la syntaxe devient un peu lourde si le nombre de fichiers de votre module se décuple.

Invoke-Pester `
  -OutputFormat NUnitXml `
  -OutputFile ".\Test-Pester.XML" `
  -CodeCoverage @('.\Sources\Credentials.ps1', '.\Sources\Deployments.ps1', '.\Sources\Multilingual.ps1') `
  -CodeCoverageOutputFile ".\Coverage-Pester.xml"

La capture d’écran suivante est le résultat de la commande ci-dessus et fait la démonstration de la métrique de couverture de code en plus de fournir le détail des commandes manquées. Celles-ci sont les commandes qui n’ont pas été exécutées par la suite de tests et sont un bon indicateur d’où il faut commencer à regarder pour augmenter la couverture de votre code. Habituellement, ma valeur plancher pour cette métrique tourne autour de 50 %, mais c’est purement subjectif. Le plus haut le mieux.

Métrique #3 – Analyse du code

Avoir du code standard à travers une solution est essentiel puisque cela permet d’augmenter la productivité de votre organisation quand vient le temps de la maintenance. Cela est encore plus vrai sur des projets de même nature où l’architecture logicielle est similaire et que seules les règles d’affaires changent. Certains programmeurs détestent avoir un outil leur disant que ce qu’ils ont fait n’est pas correct. J’ai toujours la même approche avec ce genre de situation : ne pas tuer le messager. Ces outils existent pour assurer un certain niveau de qualité et de standard. Si une règle n’a pas de sens pour vos développeurs, il est toujours possible de la désactiver.

En exécutant la commande suivante :

Invoke-ScriptAnalyzer .\Sources\

Nous obtenons ce résultat.

Osmose technologique

Il est possible d’automatiser cette collecte en combinant nos deux outils. Le code suivant est une implémentation toute simple intégrant PSScriptAnalyzer à un test Pester. Tel que démontré à la ligne 17, toutes règles transgressées briseront le test.

Describe ': Given the PowerShell Scripts Analyzer' {
    BeforeAll {
        Push-Location $PSScriptRoot
        $scriptsToAnalyze = Resolve-Path "..\Sources\"
    }

    AfterAll {
        Pop-Location
    }
       
    Context '-> When analyzing with the standard rules' {
        It "Should NOT violates any rules" {
            # Act
            $violations = Invoke-ScriptAnalyzer -Path $scriptsToAnalyze

            # Assert
            $violations | Should -Be $null
        }
    }
}

Conclusion

La cueillette de métriques est essentielle quand vient le temps d’assurer la qualité de votre code. Ces dernières peuvent ensuite alimenter un processus de CI permettant de fournir des tableaux de bord utiles (yeah!) informant un administrateur de solutions quand les choses se compliquent au niveau du code.

Restez aux aguets pour le prochain article où nous allons mettre en place les mécanismes couverts par cet article au sein d’un processus d’intégration en continu en bonne et due forme ! 🙂