Pour réaliser les manipulations décrites dans cet article, il est nécessaire de disposer d’un compte Azure DevOps avec les droits de création sur les pipelines.
Le but de cet article est de montrer comment il est possible, à partir d’un projet BizTalk Server Application, de réaliser un pipeline de build, sur Azure DevOps, permettant d’automatiser la génération d’artefacts. Ces artefacts serviront à déployer l’application BizTalk en lien avec le projet BizTalk Server Application.
Le projet BizTalk Server Application choisi pour cette démonstration est celui décrit dans l’article suivant.
Pour la création du pipeline de build, il faut se rendre dans l’onglet Pipelines/Builds du projet Azure DevOps relatif au projet TFS concerné (pour rappel, le portail Azure DevOps est accessible ici) :
Nous allons créer un nouveau pipeline en cliquant sur New Pipeline. Il faut ensuite sélectionner la source sur laquelle le pipeline se connectera. Il y a un certain nombre de choix. Dans notre cas, nous choisirons logiquement Team Foundation Version Control.
Il faut noter qu’avec d’autre source comme Azure Repos Git, il est possible de construire notre pipeline entièrement en YAML. Cela n’est pas encore possible pour les dépôts TFVC.
Après avoir sélectionné le chemin d’accès aux sources utilisées, il est possible de choisir un template de pipeline. Cela permet de faciliter la mise en place de pipelines de build couramment utilisés. Cependant, dans notre cas, nous sélectionnerons start with an Empty Job.
Une fois créé, notre pipeline contient la première étape de récupération de sources que nous venons de paramétrer. Ensuite, on y trouve une liste de jobs. Par défaut, il n’y a qu’un seul job.
Il est nécessaire d’indiquer l’agent utilisé pour exécuter le pipeline (la documentation Microsoft sur les agents se trouve ici). Il existe plusieurs types d’agent en fonction de l’environnement de compilation voulu (macOS, Ubuntu, etc.) et du fait que l’on héberge soi-même l’agent ou pas (Hosted ou On Premise). Dans notre cas, nous choisirons Hosted pour qu’Azure s’occupe d’héberger notre agent et donc ne pas s’en soucier. Mais il est également possible d’installer un agent sur un serveur. Il compilera nos sources sur la machine en question.
De plus, pour chaque job, il faut configurer l’agent utilisé, le plan d’exécution (parallélisme et temps maximum d’exécution) et les jobs dont elle serait dépendante. Pour plus de facilité, il est possible d’hériter de l’agent du pipeline. Cela sera notre cas.
Pour la génération d’artefacts nécessaires au déploiement de notre application BizTalk, nous allons créer une nouvelle tâche dans notre job. En cliquant sur le signe +, à droite du job, et en recherchant Visual Studio build, il est possible d’ajouter cette tâche au job.
Concernant la configuration de la tâche, outre son nom, il est important de définir la solution Visual Studio à compiler. Il est possible d’utiliser un masque pour définir plusieurs solutions. Il faut également choisir la version de Visual Studio à utiliser, si ce n’est pas la dernière. Pour finir, la compilation est entièrement paramétrable (arguments, configuration de build, parallélisme, récupération des Nuget Packages, etc.).
Dans notre cas, nous choisirons Visual Studio 2015 et un masque **\*.sln afin de prendre en compte l’ensemble des solutions à partir de la racine définie à la création du pipeline.
Cette tâche permet de compiler les sources voulues. Malheureusement, le résultat de cette compilation ne sera pas exploitable dans Azure DevOps pour un déploiement. Il est nécessaire, pour cela, d’ajouter une tâche supplémentaire : Publish build artifact.
Cette tâche va permettre de construire un artefact de build. C’est-à-dire un container renfermant le résultat de notre compilation et qui sera, très probablement, mis à disposition de pipelines de release pour leur déploiement.
À ce stade, il faut donner le nom de la tâche et de l’artefact. Mais il faut surtout définir le chemin vers le résultat de notre compilation et l’emplacement de l’artefact. Cet emplacement peut être Azure Pipelines (et donc pris en charge par Azure DevOps) ou un fichier partager auquel l’agent aurait accès. Nous choisirons Azure Pipelines pour plus de simplicité.Après avoir sauvegardé, notre pipeline est prêt à fonctionner.
Il est courant de vouloir variabiliser des compilations. Azure DevOps propose un onglet Variables au sein du pipeline.
Il est ainsi possible de déclarer des variables, puis de les utiliser tout au long des différentes tâches du pipeline grâce à leur nom. J’ajoute qu’il est possible d’ajouter des variables de type password (en cliquant sur le cadenas qui apparaît à droite de la valeur). Ce type de variable pourra être modifié ultérieurement, cependant la valeur restera secrète.
Le pipeline que l’on vient de construire peut être déclenché manuellement, mais nous pouvons aussi choisir d’automatiser son exécution. Pour cela, l’onglet Triggers permet de définir si l’on veut activer l’option Continuous integration et lancer le pipeline à chaque synchronisation des sources vers le dépôt central. Il est possible, pour TFVC, d’activer l’option Gated check-in qui force le contributeur à compiler son code avec succès avant le déclenchement.
La partie Scheduled et Build completion (pour un déclenchement en fonction d’un autre pipeline de build) est également très utilisée.
En sélectionnant votre pipeline, après une ou plusieurs exécutions, la liste des différentes instances de build est disponible.
En cliquant dessus, Azure DevOps montre l’ensemble des tâches exécutées pour cette instance. Chaque tâche est cliquable pour inspecter les logs associés.
L’onglet Summary propose même le résumé de l’instance avec les changesets associés, les warnings ou erreurs apparus au moment de l’exécution, les artefacts créés (et téléchargeables) et le nombre de déploiements réussis utilisant ces artefacts.
