11 Jan 2016

PowerShell et Legacy Code, boostez vos livraisons et reprenez le contrôle

Nous allons nous intéresser ici à l’automatisation des livraisons et plus particulièrement aux problèmes malheureusement bien connus de configuration dans les divers environnements.

Le constat

Chaque environnement nécessite ses propres configurations (url de webservice, endpoint & bindings, chemins vers les fichiers de logs, clés de configuration, …).

Lors de chaque livraison les développeurs et les équipes techniques en charge de la livraison sont souvent contraints de se synchroniser afin de définir les configurations qui seront appliquées dans chaque environnement ou « bidouiller » les installations (copier les anciens web.configs sur les nouvelles installations, essais de configuration « en live», …).

Le problème posé

Comment mettre à jour l’ensemble des configurations d’un logiciel de manière automatique, fiable et sécurisée lors des livraisons dans les différents environnements ?

Note : le code legacy peut ajouter une complexité supplémentaire dans la mesure où l’application a été développée plusieurs années en arrière par des collaborateurs, qui, bien souvent ne font plus partie de la structure.

Le défi à relever

L’objectif est d’uniformiser l’ensemble des fichiers configuration entre les environnements dans le but d’en dégager une structure commune invariable ainsi qu’une partie variable, sur laquelle nous agirons.

Outre l’automatisation, et surtout dans le cadre d’un projet Legacy, cette action permettra la compréhension, la réappropriation et la maintenabilité des fichiers de configuration du logiciel. Nous verrons par la suite que ça n’est souvent pas une chose facile… Mais que l’investissement est clairement négligeable face au ROI !!!

L’idée

L’idée est de fournir aux équipes techniques (nos Ops) un script d’automatisation destiné à mettre à jour l’ensemble des configurations de l’application en toute autonomie, sécurité et fiabilité lors de l’installation de l’application.

Comment ?

Vous devez surement vous dire :

  • «C’est bien beau, mais hors du monde des Bisounours, ça marche comment ???? »
  • «Avec du Legacy, c’est plié, jamais je pourrais mettre ça en place … »

Ma réponse : POWERSHELL !
powershell

Si vous pensez la mise en place impossible, désolé de vous décevoir, mais vous faites fausse route !!

Le cas sur lequel nous l’avons appliqué contenait presque tous les critères négatifs :

  • Projet fortement Legacy,
  • Perte de la connaissance métier due aux collaborateurs sortis du projet,
  • Fichiers de configuration très divergents entre les différents environnements (manque de clés, de valeurs, aucune connaissance des éléments présents …)
  • Fichiers de config « custom » à chaque développeur

Résultat

Aucune maitrise des éléments présents dans les fichiers de configuration, une personne à plein temps sur le sujet des livraisons … et des livraisons toutes plus douloureuses les unes que les autres …

Mise en place

Dans un premier temps, l’idée va être de créer le fichier de configuration (dans notre cas un fichier web.config) « Template » sur lequel nous allons agir. Pour cela, il va vous falloir analyser chacune des lignes de de vos fichiers de config afin de voir, ce que vous utilisez, et qui nécessite d’être administré.
Et c’est ici que réside la plus grosse partie du travail !!
Une fois ce fichier « Template » fait, il vous faudra créer les fichiers suivants :

  • Config[ENVIRONNEMENT].bat : ce fichier permet de définir l’environnement, le script qui réalisera le merge, le chemin de la cible, le fichier action, et les paramètres à appliquer sur le template. Il y a 1 fichier par environnement et par serveur.

  • ConfigMerge.ps1 : ce script transforme le fichier web.config « Template » déployé lors de l’installation avec les éléments configurés dans le fichier %env%.parametres.xml. La technique utilisée consiste à remplacer les valeurs des nœuds, identifié par une clé/requête XPath, par la valeur définie. Nous ne fournirons pas ce fichier.
  • [ENVIRONNEMENT]Cible.xml : ce fichier définit le chemin du fichier web.config qui subira les modifications (notre « Template » précédemment créé). Il y a 1 fichier par environnement et par serveur.

  • Fichier actions.xml : ce fichier contient les actions (requêtes XPath) identifiées par des clés qui seront exécutées par le PowerShell. Il y a 1 fichier pour tous les environnements.

  • Fichier parametres.xml : ce fichier contient l’association clé/valeur à remplacer dans le fichier « Template ». Il y a 1 fichier par environnement et par serveur.

Avec cette arborescence :

Arborescence

Placez les fichiers « actions.xml » et « ps1 » dans le dossier « Projet » du fait qu’ils sont communs à tous les environnements.

On y est, fin de la partie technique !

Le nerf de la guerre : le ROI … Quelques pistes pour vendre les PowerShell au projet :

Pour être clair, dans un contexte de rush, les remarques de type :

  • « On n’a pas le temps, on le fera dans une prochaine version »,
  • « Ok, on se note ça et on étudie »,
  • « Franchement, on fait comme ça depuis le début et ça fonctionne très bien…» (ou pas ),
  • … (la liste est encore longue …)

Seront monnaie courante lorsque vous allez parler de PowerShell … Mais pas à juste titre !!

 

Pour preuve, le tableau ci-dessous va mettre en avant notre retour d’expérience sur notre projet fortement legacy et peu maitrisé.

Sans PowerShell Avec PowerShell
Actions / détail
  • Une personne à plein temps pour réaliser les livraisons
  • Des environnements instables et non maitrisés
  • Des modifications de fichier de config durant les installations
  • Stress à chaque livraison
  • Risque de perte de connaissance en cas de départ de la personne en charge des livraisons
  • Difficultés pour comparer le nouveau et l’ancien fichier de configuration
  • Livraison réalisable par n’importe quelle personne de l’équipe
  • Paramétrage rapide et sécurisé
  • Aucune manipulation à réaliser lors des installations donc réduction du nombre « d’erreur humaines »
  • Maitrise des environnements
  • Contexte plus serein avec les équipes techniques
  • Vérification en un coup d’œil
Temps
  • 1 Personne à plein temps
  • Temps de réalisation du fichier Template (environ 1 journée)
  • 10 minutes max par livraison
  • Temps d’exécution des PowerShell quasi nul

 

En définitive, l’effort unique réside en la mise d’équerre des fichiers de configuration des environnements pour dégager la structure du fichier « Template » (1 à 2 jours en moyenne)…

 

Petite astuce : si vous utilisez la méthodologie agile, définissez cette tâche en tant que « technical story », le temps sera estimé et l’ensemble de l’équipe se rendra compte du gain lors de la future livraison.

 

Pour rappel, il a été question dans notre cas de libérer une ressource sur le projet… je pense que l’argument n’est clairement pas négligeable !

D’autre part, nous avons pu, grâce à ce dispositif, prendre une cadence de deux livraisons en recette par semaine en ne consommant que 20 minutes d’une ressource.

 

Je vous laisse faire le calcul … … …

 

Pour aller plus loin :

Pour continuer, il vous est aussi possible de lancer automatiquement les PowerShell lors de votre installation en le paramétrant dans le post-build de votre application.

Il faudra que vos PowerShell détectent l’environnement sur lequel ils se trouvent afin d’aller exécuter automatiquement le fichier Config[ENVIRONNEMENT].bat … et le tour et joué !

Autre astuce pour terminer, si ça n’est pas le cas sur votre projet, migrez vos sources vers le contrôleur de code source et configurez les builds automatique pour encore plus d’automatisation, de rapidité et de maitrise !!

Share