8.3 : PowerShell dans un pipeline CI/CD

Sophie regarde le script de rapport, maintenant planifié et envoyé automatiquement par email : « Ce script vit sur un seul serveur, dans un coin. Le jour où quelqu’un le modifie par erreur, ou où on veut le déployer sur un nouveau serveur, comment on s’assure que tout continue de fonctionner ? » C’est le rôle d’un pipeline CI/CD (Intégration Continue / Déploiement Continu) : tester et déployer un script automatiquement, à chaque modification, plutôt que de le faire évoluer à la main sur un serveur isolé.

Pourquoi un script d’administration mérite aussi un pipeline

On associe souvent le CI/CD au développement d’applications, mais le principe s’applique tout aussi bien à un dépôt de scripts PowerShell comme le module NordikaTools construit en section 6 : à chaque modification poussée sur le dépôt Git, on peut automatiquement vérifier que le code ne contient pas d’erreur de syntaxe évidente, exécuter les tests s’ils existent, puis déployer la nouvelle version sur les serveurs concernés.

GitHub Actions : un pipeline simple à mettre en place

GitHub Actions permet de définir un pipeline directement dans un fichier YAML versionné avec le code, sans infrastructure supplémentaire à gérer. Un exemple minimal qui vérifie la syntaxe d’un script à chaque push :

# .github/workflows/verification-scripts.yml
name: Vérification des scripts PowerShell

on: [push]

jobs:
  verifier:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Analyse statique avec PSScriptAnalyzer
        shell: pwsh
        run: |
          Install-Module -Name PSScriptAnalyzer -Force -Scope CurrentUser
          Invoke-ScriptAnalyzer -Path .\NordikaTools -Recurse -Severity Warning

PSScriptAnalyzer (déjà mentionné en filigrane depuis la section 5 avec les bonnes pratiques d’écriture) est l’outil officiel Microsoft d’analyse statique : il détecte les mauvaises pratiques (variables non utilisées, verbes non approuvés vus en 2.1, alias déconseillés dans un script) avant même que le code n’atteigne un serveur de production.

Azure DevOps : l’alternative en environnement Microsoft

Dans un environnement déjà largement outillé Microsoft (Azure, Microsoft 365, comme évoqué en 8.2), Azure DevOps Pipelines propose une logique similaire, avec sa propre syntaxe YAML :

# azure-pipelines.yml
trigger:
  - main

pool:
  vmImage: 'windows-latest'

steps:
  - task: PowerShell@2
    displayName: 'Analyse statique avec PSScriptAnalyzer'
    inputs:
      targetType: 'inline'
      script: |
        Install-Module -Name PSScriptAnalyzer -Force -Scope CurrentUser
        Invoke-ScriptAnalyzer -Path .\NordikaTools -Recurse -Severity Warning

Tester réellement le code avec Pester

Au-delà de l’analyse statique, le framework Pester (l’équivalent PowerShell des frameworks de tests unitaires classiques) permet de vérifier que les fonctions du module se comportent réellement comme attendu :

# NordikaTools.Tests.ps1
Describe "Test-ServiceCritique" {
    It "Ne lève pas d'erreur pour un service existant" {
        { Test-ServiceCritique -NomService "Spooler" } | Should -Not -Throw
    }
}

Ce fichier de test s’exécute ensuite dans le pipeline, avant tout déploiement :

  - name: Exécuter les tests Pester
    shell: pwsh
    run: |
      Install-Module -Name Pester -Force -Scope CurrentUser
      Invoke-Pester -Path .\NordikaTools.Tests.ps1 -CI

Retour d’expérience terrain : dans la plupart des équipes IT, tester des scripts d’administration système reste moins systématique que pour du code applicatif classique — et c’est souvent une erreur. Un test Pester aussi simple que « la fonction ne lève pas d’erreur sur un cas normal » suffit déjà à détecter une régression avant qu’elle n’atteigne un script planifié en production, comme celui construit en section 8.

Déployer automatiquement après validation

Une fois l’analyse et les tests passés avec succès, le pipeline peut copier le module mis à jour directement sur les serveurs concernés, en s’appuyant sur le Remoting vu en section 7 :

  - name: Déployer sur les serveurs Nordika
    shell: pwsh
    run: |
      $serveurs = Get-Content -Path ".\serveurs-production.txt"
      Invoke-Command -ComputerName $serveurs -ScriptBlock {
          Copy-Item -Path "\\nas-nordika\deploiements\NordikaTools" `
                     -Destination "$env:ProgramFiles\WindowsPowerShell\Modules\" -Recurse -Force
      }

Point de vigilance : ce dernier bloc combine plusieurs sujets déjà vus (Remoting en section 7, sécurité des comptes de service en section 6) — dans un vrai pipeline de production, les identifiants utilisés pour se connecter aux serveurs Nordika ne doivent jamais apparaître en clair dans le fichier YAML, mais provenir des secrets chiffrés propres à la plateforme CI/CD (GitHub Secrets, Azure DevOps Variable Groups), un principe qu’on retrouvera de façon plus générale en section 9.

Un exemple concret Nordika : le cycle complet

1. Un administrateur modifie une fonction du module NordikaTools sur son poste
2. Il pousse la modification sur le dépôt Git de l’entreprise
3. Le pipeline se déclenche automatiquement : PSScriptAnalyzer vérifie le style, Pester exécute les tests
4. Si tout passe, le module mis à jour est déployé sur l’ensemble des serveurs concernés, via Invoke-Command
5. Aucune connexion manuelle à un serveur n’a été nécessaire, et chaque étape est tracée dans l’historique du pipeline

Source officielle : la documentation Microsoft PSScriptAnalyzer (module officiel sur la PowerShell Gallery, vue en 6.1) et le framework Pester constituent les deux références communautaires les plus largement adoptées pour fiabiliser du code PowerShell avant sa mise en production.

Retenez l’idée centrale de cette leçon : un pipeline CI/CD ne remplace aucune des notions vues jusqu’ici — il les orchestre. PSScriptAnalyzer s’appuie sur les bonnes pratiques de la section 5, les tests Pester valident les fonctions de la section 5 et 6, et le déploiement final utilise le Remoting de la section 7. C’est la synthèse naturelle de tout ce que Nordika a construit depuis le début de cette formation.

Dans la prochaine leçon, le quiz de fin de section 8 pour valider planification, envoi d’email et intégration CI/CD.