Mise en place d’un pipeline de Continuous Delivery avec Azure DevOps et Azure (Partie 2)

Précédemment dans la Partie 1, nous avons vu comment builder, tester et générer les binaires/scripts de déploiement en local. Dans cet article, nous allons mettre en place le build correspondant dans Azure DevOps.

Azure DevOps ?

Anciennement TFS (version on-premise) et VSTS (version cloud) est devenu Azure DevOps Server (version on-premise) et Azure DevOps (version cloud). C’est un outil tout-en-un qui a beaucoup évolué au fil de temps et continue de le faire. Il propose les fonctionnalités suivantes:

• Boards : suivi performant des tâches avec des tableaux Kanban, backlogs, tableaux de bord d’équipe et rapports personnalisés.
• Repos : repos privés/public Git illimités hébergés dans le cloud pour votre projet.
• Pipelines : processus CI/CD qui fonctionne avec le langage, la plateforme et le cloud de votre choix.
• Test Plans : une solution tout-en-un de tests exploratoires et planifiés.
• Artifacts : flux de packages Maven, npm et NuGet provenant de sources publiques et privées.

Azure DevOps est gratuit jusqu’à 5 membres. Ce qui veut dire que vous pouvez en avoir un gratuitement afin d’expérimenter ou héberger vos repos/projets privés.

Dans cet article, nous allons utiliser Azure Pipelines pour mettre en place un build d’intégration continue qui va builder, tester et générer les artefacts qui seront déployables dans nos différents environnements. La mise en place d’un pipeline CD implique la notion de “build once, deploy many”. Cela veut dire qu’on builde une version une fois et c’est cette même version (binaires/scripts) que nous allons déployer dans nos différents environnements DEV/UAT/STAGING/…/PROD en modifiant uniquement les fichiers de configuration. Nous verrons le déploiement dans la Partie 3 de cette série.

Mise en place du build

• Cliquer sur Pipelines ==> New Pipeline

• Choisissez le “Use the classic editor”. Vous pouvez choisir d’avoir votre pipeline définit avec un YAML.

• Choisissez votre repo. Comme vous pourrez le voir, vous pouvez choisir un repo en dehors de Azure DevOps. Ainsi, vous pouvez hoster votre code sur Github, Bitbucket, etc…. et avoir vos builds dans Azure DevOps

• Choisissez votre template. Il y’a plusieurs templates selon votre type de projet. Mais dans notre cas, nous allons partir de zéro et choisir ainsi “Empty Job”

• Configuration de base : nous allons définir le nom de la build: DemoPipelineCD-CI et choisir l’agent qui va se charger d’effectuer le travail. Azure DevOps offre des agents par défaut mais on peut configurer nos propres agents. Nous avons activé l’intégration continue, ainsi à chaque push dans le repo, le build va se déclencher automatiquement. Et dans “Options”, on définit le Build number format qui va être notre numéro de version : $(date:yy.M.d)$(rev:.r). Le $(rev:.r) va s’incrémenter automatiquement et remis à zéro chaque jour.

• Configuration de la tâche Powershell pour Builder, Tester et Publier : ici encore nous avons une panoplie de tâches. Nous choisissons la tâche Powershell et le fichier de script à exécuter build.ps1. Nous lui passons le paramètre de la version grâce à la variable de Azure DevOps $(Build.BuildNumber).

• Publication du résultat des tests: nous utilisons une tâche dédiée pour publier le résultat des tests. Cette tâche a besoin du fichier xml qui se trouve dans le dossier buildArtefacts/testresults. Je vous remets l’arborescence complète du dossier de sortie du build:

• Publication de la couverture de code : comme précédemment, nous utilisons une tâche dédiée pour publier la couverture de code : Publish code coverage results. C’est très simple, nous fournissons juste les chemins aux fichiers et dossiers issus de la prèmière tâche.

• Publication des artefacts : et enfin, nous utilisons la dernière tâche pour publier les artefacts ==> sauvegarde dans Azure DevOps pour pouvoir les récupérer afin d’effectuer les déploiements:

• Résultat final d’un build disponible ICI: l’onglet “Tests” correspond à la tâche de publication des tests, l’onglet “Coverage” à la tâche de la publication du code coverage et enfin nous avons les artefacts que nous pouvons même télécharger:

Conclusion

Nous avons mis en place le build d’intégration continue et qui génère les artefacts qui seront déployables sur les différents environnements. Ce sera le but de la Partie 3.