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.
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 :
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.
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 :
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.
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.
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 :
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 :
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.
