Release Management, l’outil de déploiement automatique proposé par Microsoft, met à notre disposition une boîte à outils assez riche qui permet de couvrir une grande majorité des besoins en termes de déploiement d’applications. On y retrouve, par exemple, les actions qui permettent de créer une base de données SQL, ou celles qui permettent de configurer automatiquement IIS. Toutefois, cet outillage proposé par Release Management se confronte à une série d’autres outils provenant des équipes projet et qui couvre très bien les besoins de déploiement de certaines applications. Tout à coup, lorsque l’on s’engage sur une modélisation de déploiement, on se retrouve partagé entre la refonte de ces outils spécifiques au profit de ceux proposés par Release Management, ou capitaliser sur l’existant. Dans cet article, nous n’allons pas tenter de répondre à cette question, car une réponse qui satisfasse tous ces besoins n’existe pas. En revanche, nous mettrons l’emphase sur la boîte à outils Release Management, et surtout sur son extensibilité qui vous permettra de faire les deux.
Actions, Tools, Components… on s’y perd un peu !
RM propose trois concepts en termes d’outillage. Les actions, les outils (Tools) et les components.
Tools
Notre point de départ sera le Tool. Un Tool est, comme son nom l’indique, un élément qui permet d’accomplir certaines actions. Dans IIS, par exemple, on peut parler d’un outil qui permet de configurer de manière automatique une instance IIS (un site web, un pool d’application…etc). Voici un exemple:
Le Tool s’appelle IIS Deployer, il fait appel à une ligne de commande (IISConfig.exe). Cette commande est déclarée comme ressource. Dans l’état, ce Tool ne peut rien faire, il n’y a aucun paramètre d’appel, ni en entrée ni en sortie.
Un Tool dans Release Management fait appel à une ressource. Cette dernière peut correspondre à un .exe, un .bat ou un .ps1, que vous avez développé, par exemple, dans le cadre d’un projet. Lors de l’utilisation du Tool, soit dans une Action, soit dans un Component, la ressource peut être référencée sans contrainte particulière. La ressource (le fichier correspondant) est copiée sur un répertoire au niveau de l’agent de déploiement Release Management. Son chemin par défaut est le suivant:
C:\Users\<UserNameForDeploymenyAgent>\AppData\Local\Temp\ReleaseManagement\<ComponentName>\<VersionNumber>
Actions
Une Action permet, en effet, de faire appel au Tool pour accomplir des opérations. Si on ouvre l’onglet Actions, vous constaterez la présence de plusieurs Actions faisant appel à des Tools, et on y retrouve des actions faisant appel à IIS Deployer
Prenons l’exemple de l’Action « Configure Application Pool »:
Cette action, une sorte d’implémentation du Tool, permet de configurer un pool d’application dans IIS. L’Action a besoin de certains paramètres d’appel qui lui sont propres. Certains paramètres sont standards, d’autres sont cryptés. Il en va de même pour toutes les Actions qui font appel au Tool IIS Deployer.
Durant la modélisation d’un déploiement, la liste des Actions est donc disponible pour faire du drag & drop sur la surface de modélisation:
Maintenant qu’on a compris le lien entre le Tool et les Actions, quid de l’extensibilité?
Components
Un Component est une Action dans la mesure où elle s’appuie également sur un Tool. De plus, un Component propose deux propriétés intéressantes:
- Source: l’endroit à partir duquel l’agent Release Management récupère la ressource à exécuter, comme on peut le constater dans la figure ci-dessous, le chemin est relatif à la sortie de la build « [Build Drop Location] »
- Configuration Variable : permet de spécifier des variables de configuration qui seront modifiées, soit avant l’installation, soit après l’installation, soit avant et après.
Regardons ensemble comment on peut créer notre propre Component
- Configure Apps –> Components –> New
- Sous l’onglet Deployment, je spécifie ce que doit faire le Component
Dans Arguments, tout ce qui est déclaré entre __xxx__ est considéré comme variable. Cette variable devra prendre une valeur lors de l’utilisation du Component
- Des variables de configuration
On sauvegarde les modifications. Nous allons maintenant utiliser ce Component dans notre workflow de déploiement. Pour ce faire, on doit d’abord le référencer de la manière suivante :
- Lancer Release Templates et sélectionner celui qui vous intéresse
- Clique droit sur Components et sélectionner « Add »
Le Component est désormais disponible dans la liste et on peut effectuer un drag & drop:
Sachez, par ailleurs, que le Component nouvellement créé peut être référencé et utilisé dans tous les Release Templates disponibles dans RM.
Conclusion
Comme mentionné précédemment, il n’existe pas une seule et unique manière dans Release Management pour composer des outils de déploiement. On a la possibilité d’utiliser les éléments proposés par défaut (Actions) ou d’en créer d’autres (Components). On peut donc considérer les Tools comme le socle d’extensibilité et de modélisation dans Release Management. Les actions faisant appel à ces Tools servent des besoins standards. Quant aux Components, ils peuvent être utilisés pour des besoins spécifiques ou pour réutiliser des scripts ou autres déjà disponibles.