Ce que j’ai appris à me construire des outils PowerShell partie 2: Automatisation de métriques avec AzureDevOps

Pour ceux et celles qui l’auraient manqué, voici le premier article de la série

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

Parlons d’automatisation

Nous nous sommes laissés avec une panoplie de métriques qui pouvaient être mises à bon escient pour aider votre organisation à bâtir des tableaux de bords utiles. (Je les adore toujours!)

Dans cet article l’emphase sera mise sur la démonstration que de bonnes pratiques de génie logiciel peuvent s’appliquer à PowerShell via des mécanismes d’intégration continue (CI) et de déploiement continu (CD) en utilisant Azure DevOps (anciennement VSTS).

Le module PowerShell faisant l’objet de la démonstration vise à automatiser des tâches de DevOps pour le produit Valo : Tombez en amour avec votre intranet.

Les étapes à accomplir sont les suivantes :

Obtenir les fichiers sources du projet
Exécuter les outils de qualité
Produire de merveilleux tableaux de bord
Publier/déployer le module

En rappel, voici l’architecture du module. Cette fois-ci cependant nous allons porter notre attention sur les scripts utilitaires pour accomplir respectivement les étapes 2 et 4.

Hypothèses du flot de travail

Avant de continuer, posons quelques hypothèses :

Du nouveau code livré par un programmeur proviendra d’une Feature branch isolée
Une demande de revue de code (pull request) sera faite sur la branche visée (dans notre cas il s’agira de la branche « develop »)
Le code est intégré dans la branche visée seulement après avoir subi une révision par les pairs

Mettre en place un pipeline d’intégration

Premièrement, nous allons créer une définition vide en utilisant la nouvelle interface utilisateur d’Azure DevOps.

Ensuite, sélectionner le type d’entrepôt (repository) et la branche visée.

Nous partirons d’un patron vide.

Ajout de tâche au patron vide

Voici donc la définition du pipeline que nous visons. À remarquer que les scripts utilitaires seront utilisés au tout début et à la fin du processus d’intégration. La tâche Pester s’obtient du Visual Studio Marketplace et les tâches de publication sont fournies par la plateforme. Avant de continuer, garder en tête qu’il s’agit toujours d’une pratique sécuritaire de sauvegarder (sans nécessairement mettre en queue) le pipeline d’intégration entre chaque étape.

Par mesure de clarté, les sections subséquentes feront référence directement au nom des tâches dans la capture d’écran ci-dessous et n’ont pas fait l’objet de traduction.

Installing Required PS Modules

Ajouter une tâche PowerShell

Donner un nom significatif à celle-ci (optionnel)
Taper le File Path afin d’indiquer quel script sera exécuté
Pour Script Path, choisir le script indiqué ci-dessous

Le script exécuté est tout simple. Il installe le NuGet Package Provider sur l’agent en cours d’exécution afin d’assurer l’accès aux modules requis.

Dans le cas de mon module, j’ai besoin de PSScriptAnalyzer comme analyseur de code et AzureRm.

# This script installs dependencies required by the Toolkit. 
# It is intended to be used by the Azure DevOps Agent and 
# is the reason why Module installations are scoped to current User.
Install-PackageProvider -Name NuGet -Force -Scope CurrentUser
Install-Module -Name PSScriptAnalyzer -Force -Scope CurrentUser
Install-Module -Name AzureRm -Force -Scope CurrentUser -AllowClobber

Pester Test Runner

La tâche Pester Test Runner, développée par Black Marble, s’obtient gratuitement à partir du Visual Studio Marketplace.

Donner un nom significatif à la tâche (optionnel)
Spécifier le dossier contenant les tests. Dans mon cas, je suis paresseux et lui indique simplement la racine du projet.
Spécifier le fichier qui contiendra le résultat des tests
Spécifier le fichier qui contiendra le résultat de couverture de code

Dans la section Advanced, forcer la version 4.0.8 et ne pas oublier de cocher la Force the use of a Pester Module shipped within this task sinon la version ne sera pas vraiment forcée… Plusieurs précieuses minutes d’intégration se sont perdues pour découvrir cette configuration 😉.

Publish Tests Results

Cette tâche est déjà préconfigurée pour la plupart des cas d’utilisation et servira à la production du tableau de bord contenant les résultats des tests : notre première métrique.

Donner un nom significatif à la tâche (optionnel)
Le format des résultats de test est NUnit
La valeur par défaut peut être laissée telle quelle si vous avez suivi cet article jusqu’à maintenant. Référez-vous à votre configuration dans la tâche Pester.

Publish Code Results

Cette tâche est aussi préconfigurée pour la plupart des cas d’utilisation et servira à la création de notre deuxième tableau de bord, joie!

Donner un nom significatif à la tâche (optionnel)
Choisir JaCoCo comme outil de couverture de code
Utiliser la configuration de la tâche Pester pour le nom de fichier adéquat. Je recommande l’utilisation des variables d’Azure DevOps pour référencer le fichier en question.

Publish to PowerShell Gallery

Finalement, la dernière étape de notre pipeline d’intégration est de déployer le module sois sur un environnement privé qui peux être utilisé à l’interne par votre organisation ou comme dans le cas présent, être déployé publiquement afin de partager ces fonctionnalités avec la communauté.

Donner un nom significatif à votre tâche (La répétition est la clé ici)
Pour Script Path, choisir le script indiqué ci-dessous
Le script utilise un argument qui sera défini comme une variable privée du pipeline d’intégration. Ne vous inquiétez pas, je vais couvrir cette partie aussi.

Voici le contenu du script qui sera utilisé pour la publication vers PowerShell Gallery.

[CmdletBinding()]
Param (
    [ValidateScript({-not([string]::IsNullOrEmpty($_))})]
    [Parameter(Mandatory=$true)]
    [string]$NuGetApiKey
)

$moduleName = "Nexus.Valo.Modern"
Push-Location $PSScriptRoot

try {
    Write-Output "Creating module staging folder"
    $module = New-Item -Name $moduleName -Type Directory

    Write-Verbose "Copying module scripts to staging folder"
    Get-ChildItem -Recurse -Path ".\Sources" | ForEach-Object {
        Write-Verbose "Copying $($_.FullName) to $($module.FullName)"
        Copy-Item $_.FullName -Destination $module.FullName -Force
    }

    Write-Output "Publishing module to PowerShell Gallery"
    Publish-Module -Path $module.FullName -NuGetApiKey $NuGetApiKey

} finally {
    if(Test-Path $moduleName) {
        Write-Warning "Removing module staging folder"
        Remove-Item $moduleName -Force -Recurse
    }

    Pop-Location
}

Et maintenant, la pièce manquante est celle de définir une variable privée qui contiendra la clé d’API NuGet qui s’obtient de PowerShell Gallery directement sous votre profil.

À partir du menu du pipeline, appuyer sur Variables. Assurez-vous d’avoir sélectionné Pipeline variables. Appuyez ensuite sur Add. Attribuez-lui le même nom que l’argument de script Publish-NexusValo.ps1 et n’oubliez pas d’activer le petit cadenas au bout de la ligne afin de vous assurer que votre clé d’API reste secrète!

Nous avons officiellement terminé avec la plomberie, ceux encore parmi nous sont officiellement des guerriers DevOps!

Et maintenant… des tableaux de bord!

Il est maintenant temps de voir ces métriques présentées de manière conviviale permettant d’avoir un visuel clair sur le code.

Maintenant, appuyez sur le bouton Queue, attendez qu’un agent soit disponible et sur l’exécution du pipeline d’intégration.

Une fois l’intégration complétée, nous pouvons basculer entre les tests et la couverture de code, télécharger l’artéfact produit et même avoir un aperçu de la journalisation de l’agent. Azure DevOps est vraiment un bel outil permettant de monitorer de près l’évolution de votre logiciel.

And on PowerShell Gallery:

Conclusion

Voici donc le tour de roue complet. Dans un monde où la complexité ne cesse d’augmenter, avoir en place des bonnes pratiques de génie logiciel telles que l’écriture systématique de tests, de l’analyse de code, de l’intégration et du déploiement continu, est un incontournable. Ceux-ci permettront à votre organisation de sauver temps et argent mais aussi de nombreuses migraines à votre équipe de développement.

Restez à l’affut pour la prochaine série d’articles qui démontreront comment nous, chez Nexus, assurons un processus de génie logiciel visant à standardiser, automatiser et accélérer des déploiements d’intranets Valo Moderne en utilisant notamment PowerShell et les générateurs Yeoman.