Comment variabiliser ses bindings BizTalk dans Azure DevOps ?

Bastien
Publié par Bastien
Catégorie : BizTalk / DevOps / VSTS
05/10/2020

Dans cet article, nous allons voir comment variabiliser nos bindings BizTalk lors de nos déploiements automatiques à l’aide d’Azure DevOps. Nous verrons également comment avoir une configuration différente en fonction de l’environnement de destination et ce, de manière automatique. Enfin, nous terminerons avec une petite astuce pour gérer des bindings un peu plus complexes.

Prérequis

Il s’agit d’abord de mettre en place notre “BizTalk Server Application Project” comme expliqué dans l’article suivant : BizTalk Server Application Project : Mise en place.

Ensuite, l’intérêt de variabiliser ses bindings est également de pouvoir le faire en fonction de l’environnement de déploiement. C’est pourquoi nous devons au préalable, dans Azure DevOps, créer ces différents environnements dans Deployment groups comme c’est le cas dans l’exemple ci-dessous :

Deployment groups

Variabilisation des bindings

Ajout des variables dans le fichier de bindings

Dans le fichier de bindings présent dans Visual Studio (dans notre exemple, le fichier Bindings.xml), il s’agit de variabiliser tous les champs souhaités de la façon suivante :

<SendPort Name="SndP_IAM_Employee" IsStatic="true" IsTwoWay="false" BindingOption="0" AnalyticsEnabled="false">
...
<PrimaryTransport>
<Address>$(File_Path)\%SourceFileName%</Address>
...
</SendPort>

Comme vous pouvez le constater, c’est la variable $(File_Path) du champ Address qui nous intéresse ici.

A noter que ces variables peuvent être n’importe où à l’intérieur d’une balise XML comme un emplacement de réception, une instance d’hôte, l’URI d’un port d’envoi, etc.

 

Création des variables dans Azure DevOps

Une fois que toutes les données souhaitées ont été “variabilisées” dans le fichier de bindings, il faut maintenant les créer dans Azure DevOps. Pour cela, aller dans la définition de votre release et sélectionner l’onglet Variables.

Cf. capture d’écran ci-dessous :

Pipeline variables

Ici, nous voyons que nous avons autant de lignes clé/valeur que nous avons d’environnements. C’est tout l’intérêt d’avoir configuré au préalable les différents groupes de déploiement.

Si la valeur de votre variable est la même sur tous les environnements, sélectionner le scope Release.

Conclusion

Et voilà, c’est aussi simple que cela ! Quand le déploiement sera initié, les valeurs seront automatiquement ajoutées au fichier de configuration.

La variabilisation du fichier de bindings peut être quelque peu fastidieuse à faire la première fois mais le jeu en vaut la chandelle. Nous y gagnons en flexibilité, en qualité, etc. C’est vraiment un must-have dans notre approche DevOps de CI/CD.

Pour aller plus loin

Il arrive souvent d’avoir des configurations radicalement différentes d’un environnement à l’autre. Je pense notamment à un adaptateur différent, un pipeline différent, etc.

Dans cette situation, notre façon de faire décrite précédemment atteint vite ses limites. Nous utilisons donc un petit workaround basé sur les commentaires XML. Voici l’astuce :

Dans votre fichier de bindings, vous pouvez utiliser les variables telles que ci-dessous :

<SendPortCollection>
<SendPort Name="SndP_HUBRH_Employee_BDZ" IsStatic="true" IsTwoWay="false" BindingOption="0" AnalyticsEnabled="false">
...
$(Comment_If_PRD)
<PrimaryTransport>
<Address>$(File_Path)\%SourceFileName%</Address>
<TransportType Name="FILE" Capabilities="11" ConfigurationClsid="5e49e3a6-b4fc-4077-b44c-22f34a242fdb" />
...
</PrimaryTransport>
$(End_Comment_If_PRD)
$(Comment_If_TST)
$(Comment_If_QUA)
<PrimaryTransport>
<Address>$(File_Path)\%SourceFileName%</Address>
<TransportType Name="SFTP" Capabilities="523" ConfigurationClsid="f75aeff5-ebc7-4e7c-a753-fdd68ab45c95" />
...
</PrimaryTransport>
$(End_Comment_If_TST)
$(End_Comment_If_QUA)
...

Puis dans l’onglet Library d’Azure Devops, configurer les Variable groups suivants :

Configuration des variable groups

Chaque variable group contient une liste de variables. Nous vous recommandons d’ailleurs d’utiliser ces Variable groups si vous avez des données communes à vos différentes releases.

Dans notre exemple, si nous allons dans l’onglet Variable groups de notre release, nous avons la configuration suivante :

Définition des variable groups

Et voilà ! Simple mais efficace. Avec cette astuce, les balises XML seront mises en commentaires selon l’environnement de déploiement.

Nous pouvons ainsi gérer des bindings BizTalk qui peuvent être très différents d’un environnement à l’autre.