En retombant sur un article de Michel et avec mes dernières années passées dessus, j’ai trouvé quelques raisons de plus de passer à PowerShell. Les voici.

Raison 1 : PowerShell fait le mur

Depuis quelques temps, PowerShell, encore en version préliminaire certes, est disponible sous Linux ou MacOS et tout ça, en OpenSource : https://github.com/powershell/powershell

C’est encore une version Alpha, mais c’est déjà bien prometteur et puis il faut bien commencer un jour !

powershell-on-linux

Raison 2 : PowerShell est modulaire

Bien sûr, on peut écrire des programmes ou des scripts supplémentaires pour pallier le manque d’une commande. Mais depuis la version 5, on peut installer et donc importer des modules via une Gallery, à la manière de packages NuGet pour un projet .Net. C’est d’ailleurs une base de NuGet qui est utilisée pour gérer ces briques.

La gallery est accessible ici : http://www.powershellgallery.com/

Pour l’installation, rien de plus simple :

PS C:\Windows\system32> Install-Module PSScriptAnalyzer -Force -SkipPublisherCheck

PS C:\Windows\system32> Import-Module PSScriptAnalyzer

PS C:\Windows\system32>

Le module qui permet d’analyser le script est installé. On en reparlera un peu plus loin.

Raison 3 : On a les mêmes outils que les Devs

Exit notepad ou même Notepad++, on peut écrire des scripts PowerShell dans les différentes versions de Visual Studio avec tous les avantages de ces outils : auto-complétion, formatage, …

Extension pour Visual Studio 2015

Extension pour Visual Studio Code

powershell-visualstuio-extension

Raison 4 : PowerShell est testable

Et pourquoi ne pas tester les scripts ? Comme sur du « développement » classique, on peut écrire des tests, avec des Mocks si nécessaire et même avoir de la couverture. C’est Pester qui va fournir le framework nécessaire pour écrire et exécuter les tests :

powershell-pester

Raison 5 : On peut savoir si on écrit bien ses scripts

Même si le nombre de règles est encore peu important – une petite cinquantaine – on peut analyser la qualité de ses scripts.

Pour un peu, on pourrait s’attendre à voir arriver des analyses de scripts PowerShell dans SonarQube un jour !

powershell-psscriptanalyzer

Raison 6 : Et pourquoi les Ops ne travailleraient pas un peu comme des Devs ?

Avec tout ce qu’on a vu, IDE, Tests, Analyse de CodeScripts, pourquoi ne pas envisager d’adopter des pratiques de développeurs ?

La première chose, c’est de version contrôler les scripts et autres modules qu’on développe en/pour PowerShell. C’est aussi utile dans des équipes Ops qui sont souvent constituées de plus d’une personne. Utiliser un VCS devrait même devenir naturel pour les équipes Ops.

La deuxième chose est qu’on peut tester et analyser la qualité des scripts, pourquoi ne pas faire de l’intégration continue et packager le tout ? Pourquoi ne pas continuer et mettre tout ça à disposition via une galerie ?

Alors ?

PowerShell est un outil très puissant et très vivant. Chaque version apporte encore plus de puissance à ce langage. L’ouverture du code sur GitHub et les versions non-Windows devraient l’aider à devenir un langage de premier choix pour les Ops de tous bords.