Intégration continue de scripts PowerShell (CI)*

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 PesterLire la suite

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

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

Varnish devant WordPress sur Apache

Varnish-Cache

Alors je ne sais pas si vous avez remarqué, mais le blog va (un peu) plus vite à charger ces derniers temps ? Après mon serveur n’est pas monstrueux non plus (1 cœur/2GB RAM : ne vous amusez pas à me faire un DDOS, ça tombera probablement dès la 10ème connexion simultané…)

Bref, j’ai suivi une partie de cet article pour essayer d’améliorer, modestement les performances du blog, j’ai déjà :

  • Mis facilement WP Super Cache en place, et fait les réglages associés ;
  • Ajouté le Plugin WP Smush pour compresser les images sans pertes (toujours ça de gagné) ;
  • Utilisé gtmetrix.com et webpagetest.org pour savoir quoi améliorer sur le site ; et
  • J’ai fait un peu de ménage dans les « grosses » images qui étaient sur la page d’accueil, pour éviter qu’elles ne soient re-sizées par votre navigateur, et vous servir de suite celle à la bonne taille.

Bon après j’ai sauté la partie gestion des commentaires (il n’y en a presque pas pour l’instant), et je n’ai pas encore abordé la partie base SQL. Du coup il me reste le caching avec un reverse-proxy pour continuer d’optimiser.

Optimiser pour quoi faire ?

Alors c’est très simple : … Lire la suite