BizTalk Server Application Project : Release pipeline

Florian Caillaud
Publié par Florian
Catégorie : BizTalk / DevOps / VSTS
18/02/2020

Dans cet article nous allons montrer comment déployer une application BizTalk sur un serveur BizTalk On Premise suite à la génération d’artefacts dans Azure DevOps.

Le projet BizTalk Server Application choisi pour cette démonstration est celui décrit dans cet article et les artefacts utilisés sont ceux générés dans celui-ci.

 

Prérequis

Pour réaliser les manipulations décrites dans cet article, il est nécessaire de disposer d’un compte Azure DevOps et d’une licence Visual Studio 2015 accompagnée de BizTalk 2016 Developer Tools (Feature Pack 2).

 

Agent On Premise

Afin de pouvoir interagir avec un serveur On Premise, il est nécessaire de créer un Self-hosted Windows agent. Cet agent permettra d’exécuter le déploiement de notre application sur le serveur en question. Afin de réaliser cette action, il faut accéder à la partie « Organization Settings/Agent pools » sur Azure DevOps :

 

Pools d'agent DevOps

 

En cliquant sur « Add pool », nous allons créer un pool d’agents. Il est possible d’avoir plusieurs agents travaillant en parallèle. Cependant, dans notre cas un seul agent suffira.

 

Ajouter un pool d'agent DevOps

 

Après avoir renseigné le nom du pool, il faut s’assurer qu’il aura les permissions nécessaires pour accéder à notre futur pipeline de déploiement. Nous allons également provisionner le pool pour le projet Azure DevOps voulu.

 

Ajouter un agent DevOps

 

À l’intérieur du pool, dans l’onglet « Agents », nous allons ajouter un nouvel agent en cliquant sur « New agent ».

Dans le pop-up suivant, dans l’onglet Windows, Azure DevOps fournit l’agent en téléchargement et explique comment l’installer sur le serveur cible. La documentation précise pour cette installation est présente ici.

 

Ajout Agent

 

Durant l’installation de l’agent, il est proposé de l’exécuter sous forme de service Windows (c’est conseillé). Et il faut noter que l’utilisateur choisi pour ce service doit être membre des administrateur BizTalk pour que le futur pipeline de déploiement s’exécute sans erreur.

Pour finir, il est possible qu’il faille se rendre dans les Settings du projet Azure DevOps, dans la section « Agent pools » pour ajouter le pool d’agents en sélectionnant les pools existants.

 

Pipeline de release

Une fois l’agent disponible, nous pouvons commencer à construire notre pipeline de déploiement.

 

Création du pipeline

Dans la section Pipelines/Releases du projet Azure DevOps, cliquer sur « New pipeline ».

 

Création pipeline

 

Dans un premier temps, on nous propose des templates de pipeline pour le déploiement d’un certain nombre de composants souvent utilisés. Malheureusement, dans notre cas, il faudra sélectionner « Empty job » (tout en haut) :

 

Type de stage

 

Notre pipeline, pour le moment vide, est composé de 2 parties : les artifacts et les stages.

 

Pipeline vide

 

Sélection des artifacts

Un pipeline de déploiement a besoin d’éléments à déployer. Ce seront ces fameux artifacts ou artefacts déjà décrits ici. Nous allons donc sélectionner ces éléments en cliquant sur « Add an artifact » et en sélectionnant le type de source « Build », le projet contenant le pipeline de build construit dans cet article et enfin l’artefact contenant l’archive .zip permettant le déploiement.

 

Choix de l'artefact

 

En cliquant sur « Add », on voit notre artefact. Il est possible d’en avoir plusieurs en entrée d’un pipeline de déploiement. De la même façon que les pipelines de build, nous pouvons paramétrer le déclenchement du pipeline (à une heure/un jour donné(e), au moment de la fin de l’exécution du pipeline de build, etc.).

 

Configuration des stages

La deuxième partie de notre pipeline concerne les stages. Ces stages permettent de réaliser une liste d’actions. Généralement, c’est un découpage logique qui correspond à un environnement. Cela permet de déployer les mêmes artefacts sur différents environnements (ex : DEV, TEST, UAT, PROD, etc.).

Ainsi, la première chose à paramétrer est le nom de la stage, en cliquant sur « Add a stage », et le propriétaire de la stage.

 

Nom de la stage

 

Dans la stage, en cliquant sur le lien « 1 job, 0 task », il est possible de configurer les différentes tâches à réaliser sur notre environnement :

 

Configuration du Job

 

Au sein d’une stage, il est possible d’exécuter plusieurs jobs. Chaque job est géré par un agent pool. Dans notre cas, un seul job suffira. Il faut cependant bien lui préciser que l’on utilisera le pool créé plus haut.

Pour finir, en cliquant sur le + de l’agent job, nous allons ajouter une tâche de déploiement BizTalk.

 

Tâche de déploiement BizTalk

 

Nous devons également configurer cette tâche. Dans un premier temps, il faut sélectionner le type de déploiement :

 

Create new BizTalk Application Déploie une nouvelle application. Si l’application existe déjà, elle sera totalement stoppée et désinstallée, puis elle sera réinstallée.
Update an existing BizTalk Application Concatène les changements, comme les schémas ou les maps, sur l’application encore active. Cela ne redéploye pas complètement l’application.
Install BizTalk Server Application Installe l’application sur le serveur (dans le GAC).

 

Dans un second temps, il faut renseigner l’URI de l’archive de déploiement .zip au sein de l’artefact correspondant.

 

Configuration de la Tache de Déploiement BizTalk

 

Nous pouvons alors sauvegarder notre pipeline.

 

Confirmation et autres paramétrages

Pour compléter ces explications, il faut noter, de la même façon que pour les pipelines de build, qu’il est possible de paramétrer le déclenchement des stages, les variables utilisées dans le pipeline et la rétention des différentes releases.

 

Confirmation stage

 

Mais il est également possible de définir des « confirmations » par mail, en cliquant sur les bulles à gauche et à droite de la stage. L’intérêt est double. Avant l’exécution d’une stage, on peut demander la confirmation à un groupe de personnes. Et après le déploiement sur un environnement, on peut demander la confirmation que fonctionnellement, le déploiement s’est bien passé et ainsi valider la stage. Si une confirmation post-déploiement est refusée, il est possible de mettre en place le redéploiement automatique de la dernière release valide.

 

Lancement du pipeline

Une fois notre pipeline construit, il peut être lancé en créant une release. Cette action est réalisable soit dans l’éditeur du pipeline, soit à partir de la liste des différents pipelines avec le bouton « Create Release ».

Le déploiement va alors s’exécuter et déployer l’application BizTalk sur le serveur cible.

Il est possible de suivre en temps réel le déroulement du déploiement en cliquant sur la release. Les informations sur les artefacts en entrée et les variables utilisées sont présentes.

 

Déploiement de la release

 

On peut également, en survolant les stages, cliquer sur « Logs » et ainsi voir de façon assez fine le déroulement du déploiement.

 

Logs de la release

 

Historique

Pour chaque pipeline, Azure DevOps fournit une liste des dernières releases et de leur état (succès ou échec). Le nombre de releases présentes dans l’historique est directement lié à la politique de rétention définie au sein du pipeline dans l’onglet « Retention ».

 

Historique des releases

 

Conclusion

Cet article vous permet donc de mettre en place une automatisation des déploiements de flux BizTalk. Ces déploiements sont traçable et offrent ainsi une réelle maîtrise du code déployé sur chaque environnement.

Pour finir, nous avons, ici, déployé un flux BizTalk, mais il est évidemment possible, dans une stage, d’inclure le déploiement d’autres éléments liés au flux (application Web, BDD, dossier, etc.).