Comment lancer un script DSC depuis Release Management ?

Dans cet article, nous mettrons le focus sur la manière dont on peut faire cohabiter Release Management et DSC.  Pour rappel, Release Management (anciennement InRelease) est l’outil de Microsoft qui permet d’automatiser les déploiements d’applications dans différents environnements, tout en passant par un workflow de validation. L’outil s’intègre nativement avec TFS et est donc connecté à la drop location.

DSC est l’outil d’automatisation d’une infrastructure fourni par Microsoft. Il s’appuie sur PowerShell v4 et repose sur des ressources, pour plus d’informations sur DSC, je vous invite à consulter les deux articles: Partie 1 et Partie 2.

Où se situe la frontière entre Release Management et DSC ?

En termes de fonctionnalités, il existe, en effet, un overlapentre ce que propose Release Management et DSC. Prenons un exemple simple : lorsque l’on souhaite déployer une application web IIS, l’un des pré-requis est de s’assurer que le site web existe. Créer un site web IIS est une fonctionnalité qui existe effectivement dans Release Management et dans DSC. Mais alors quelle est la différence entre les deux?  La différence réside tout simplement dans le caractère idempotent de DSC.  Rappelez-vous le fonctionnement de DSC, ce dernier vous permet de relancer autant de fois un script sans se soucier de l’état de votre système. Or, dans Release Management, il faut effectuer une vérification préalable.

Comme on peut donc le constater, un script DSC permet d’assurer l’état avant déploiement. Or, dans Release Management, on utilise une action qui fait appel à la commande IISConfig.exe. Le problème qui se pose à ce niveau est que Release Management ne permet pas de faire des branches if else.  On ne peut donc pas implémenter la même logique DSC dans Release Management. Toutefois, au-delà du fait que le branching n’est pas supporté dans Release Management, il est bien conseillé d’établir la frontière entre DSC et Release Management de la manière suivante : Tout ce qui concerne la configuration préalable au déploiement d’une application (ex: Créer un site web, configurer un application pool…etc) est implémenté via DSC. Release Management doit contenir la logique de déploiement liée purement à l’application ou aux base de données.  De cette manière, on allège considérablement les séquences de déploiement et on gagne donc en temps et en maintenance. Un autre avantage réside dans le fait qu’on découple la logique de déploiement de la configuration système nécessaire, on peut donc faire évoluer l’un indépendamment de l’autre.

Maintenant qu’on a tracé les contours entre ce qu’on peut faire avec DSC et avec Release Management, regardons ensemble comment on peut intégrer les scripts DSC dans un processus de build et déploiement. Il existe, en effet, deux façons de faire :

1. Intégrer les scripts DSC dans une build:

Release Management introduit la notion de component. Ce dernier permet de compléter la liste des actions disponibles par défaut dans RM, en cas de besoin spécifique. En effet, un component au sens Release Management, représente une utilisation spécifique d’un outil (Tool).

Pour lancer un script DSC, on va donc créer un nouveau component, qu’on appellera RunDSCScript:

La première étape consiste à créer le component, via l’écran RM:

On spécifie bien un nom, une description et le chemin à partir duquel le script DSC sera copié. Notez-bien que le chemin fait référence à [Buidl Drop Location], il s’agit bel et bien du répertoire de sortie de la build TFS.  Cela sous-entend que le fichier DSC fait bien partie du projet dans TFS et qu’il est bien compris dans le résultat de la build.

Deuxième étape :

On spécifie l’outil « Command Line Runner », la commande est « powershell » et on passe en paramètre le chemin vers le fichier DSC à exécuter. Maintenant que le component est créé, on doit ensuite le référencer dans une séquence de déploiement et l’utiliser comme suit:

Attention, le script DSC est lancé depuis l’agent de déploiement Release Management, une étape préliminaire consiste à copier le(s) scripts DSC vers l’emplacement souhaité. Dans mon exemple, j’utilise la boite à outil RM pour copier le script vers « C:\Scripts »

2. Utiliser une ressource Release Management

Une autre solution consiste à utiliser les ressources Release Management pour y stocker le script DSC. Pour ce faire, nous allons créer un outil (Tool), dans lequel nous déclarons une ressource imbriquée:

En cliquant sur « Add », on récupère le script DSC qui doit se trouver sur le serveur Release Management, nous créons ensuite le « Tool » avec la commande « powershell » et comme arguments « -file » suivi du chemin relatif du fichier DSC « .\VotreFichierDSC.ps1 ». Relatif, car les ressources RM sont ensuite copiées sur le répertoire local de l’agent de déploiement. La dernière étape consiste à créer un component qui fait appel à cet outil et ensuite le référencer dans une séquence de déploiement, au même titre que l’option 1.

Cette solution présente l’avantage de ne pas intégrer la configuration DSC dans TFS et de tout centraliser au niveau du serveur RM. Toutefois, si nous devons apporter des modifications au script  DSC, il faudra modifier le « Tool », et cela n’est pas sans impact si ce dernier est référencé dans d’autres séquences RM.

Conclusion

En l’absence d’une intégration native de DSC dans Release Management, nous remarquons qu’il existe néanmoins des moyens pour intégrer les deux outils. Cette intégration doit se faire en veillant au respect de la séparation de ce que doit faire DSC et ce qu’on doit faire dans Release Management.