Accueil › Archive pour TP Powershell › Page 7

TP Powershell

API REST en PowerShell – développez avec Polaris !

Posté le de — 4 commentaires ↓
API REST en PowerShell

Salut à tous, on va se faire un joli morceau aujourd’hui. On va voir comment développer une API REST en PowerShell et du comment coup piloter des scripts via du CURL sur linux, ou avec Invoke-RESTMethod en PowerShell.

Notez que cet article a été rédigé en collaboration avec ArnaudPETITJEAN de PowerShell-Scripting.com. Merci à lui !

C’est quoi une API REST ?

C’est un peu complexe à définir entièrement, d’ailleurs la définition de Wikipédia est floue au possible, mais je pense qu’on peut faire simple en disant que c’est simplement une API (bravo Sherlock… et si vous ne savez pas ce qu’est une API, je pense que c’est pas la peine d’aller plus loin 😉 ). Une API REST s’appelle non pas en important une bibliothèque dans un script (comme en C ou Python par exemple) mais en faisant une simple requête Web HTTP(S). L’action sera exécutée par le serveur qui expose l’API et vous pourrez exploiter le résultat directement dans votre script.

Les API REST sont à la mode depuis quelques années, notamment chez les DevOps. Elles présentent souvent les avantages d’être simples, interopérables, légères et accessibles à distance. Si vous cherchez des alternatives à REST, vous … Lire la suite

Intégration continue de scripts PowerShell (CI)*

Posté le de — Aucun commentaire ↓
Intégration continue de scripts PowerShell

*avec Azure Pipelines et GitHub

Salut à tous, vous rappelez la semaine dernière on avait parlé du module Pester pour faire des tests en PowerShell ? Cette semaine je vais vous montrer comment on fait de l’intégration continue de scripts PowerShell et l’automatisation des tests dans Azure DevOps. Notez que vous entendrez aussi parler de CI, pour Continuous Integration en anglais.

C’est quoi l’intégration continue ?

Les mots clés qui vont avec intégration continue sont :

  • automatiser ;
  • sa gestion de versions ;
  • ses tests ; et
  • être notifié de tout ça.

Pour ceux qui développent souvent, je dois enfoncer des portes ouvertes là. Pour les autres, il s’agit de d’industrialiser le déploiement de son code, sans passer forcément (mais on peut) par les lourds processus traditionnels de développement : qualification, alpha, bêta, release candidate, version de prod, etc.

Les avantages de mettre de la « CI » dans vos cafés dev sont multiples : meilleure qualité du code, suivi des développements, reporting automatisé pour les managers, diminution des délais de mise en prod, et j’en passe.

GitHub, et Azure Pipeline

Dans le dernier article, je vous ai montré comment on écrit des tests en PowerShell avec le module Pester… Lire la suite

Tests des scripts PowerShell : arrêter de « Pester »

Posté le de — Aucun commentaire ↓
tests des scripts PowerShell

Salut à tous ! aujourd’hui on va se pencher à l’intégration continue en PowerShell et plus particulièrement les tests des scripts PowerShell avec le module PowerShell Pester.

Les tests ? on s’en fou… yolo, non?

Alors, non… les tests on s’en passe, certes, bien sur les petits SI, ou pour les bout de scripts en read-only à usage unique. Mais dès que vous commencez à vouloir maintenir votre code dans le temps… Les tests ça devient bel investissement, car si effectivement c’est pas passionnant à écrire, ils permettent quand même de spécifier clairement les entrées et les sorties attendus de vos scripts et donc de s’assurer que celles-ci ne seront pas modifiée lors de vos futures mise à jour.

Donc, pour répondre à la question : dois-je écrire un jeu de tests pour mon code ? j’aurais tendance à dire :

  1. Si votre code est destiné à avoir une durée de vie supérieure à quelques mois : oui.
  2. Sinon, c’est à évaluer en fonction de la « criticité » du script que vous comptez exécuter. Exemple : un script qui modifie 150 000 comptes utilisateurs de manière d’un côté, ou de l’autre côté celui test si le port
… Lire la suite

Trouver l’emplacement d’un module PowerShell

Posté le de — 2 commentaires ↓
emplacement d'un module PowerShell

Salut à tous, aujourd’hui encore une petite astuce de commande PowerShell pour trouver l’emplacement d’un module PowerShell. Récemment j’ai eu besoin de retrouver où était installé un module PowerShell sur un de nos serveurs.

Il faut savoir que les modules PowerShell ne sont ni plus ni moins qu’un fichier texte PowerShell (extension .psm1 au lieu de .ps1) avec le code source du module et un fichier .psd1 qui décrit le module (et allez voir par ici si vous voulez en savoir plus). Il faut placer ces fichiers dans des dossiers spécifiques pour que PowerShell les trouve (comme une variable d’environnement PATH quoi).

Donc 2 options : soit vous utilisez la commande native, la version des faibles :

Get-Module -listavailable | where-Object {$_.Name -match '<ModuleName'}

Sinon à la main, je vous propose une version oneliner « qui sert à rien » mais « parce que je peux le faire » :

$env:PSModulePath.Split(';') | foreach {Write-Host -ForegroundColor Yellow $_ ; If (Test-Path $_){Get-ChildItem -Path $_ | foreach {if($_.Name -match "<ModuleName"){Write-Host @($_.name+'-'+$_.FullName)}}}}

Les plus attentifs auront noté que je cherche dans ce second cas un nom de dossier, et pas un nom de module, dans les emplacements possibles pour un module … Lire la suite