Intégration et livraison en continu avec TeamCity, Bitbucket et Azure

Le mouvement DevOps vient briser depuis quelques années le cycle de développement traditionnel des applications. Cette nouvelle approche est de plus en plus adoptée par les entreprises. Le DevOps offre une meilleure cohésion et communication entre les développeurs (Dev) et les chargés d'opération (Ops), permettant ainsi d'accélérer la livraison des applications et rendre celles-ci plus robustes en détectant les erreurs plus tôt.

L'un des concepts clés du DevOps est l'intégration continue. L'intégration continue (CI, pour Continuous Integration) représente un élément primordial dans un environnement de développement agile. L'intégration continue regroupe un ensemble de pratiques visant à favoriser l'industrialisation du développement d'une application.

La mise en place de l'intégration continue nécessite le recours à un serveur d'intégration continue et gestionnaire de versions. Le serveur d'intégration continue offre des fonctionnalités permettant d'assurer la compilation du code, l'exécution des essais unitaires, le packaging et le déploiement.

Au niveau du déploiement, il est également possible de configurer son serveur d'intégration pour automatiser le déploiement. Ce dernier se chargera d'exécuter les scripts de configuration des environnements d'exécution et déployer l'application, sans nécessiter une intervention humaine.

Il existe sur le marché plusieurs serveurs d'intégration continue, dont Jenkins, SonarQube, Team Foundation Server ou encore TeamCity. Dans le cadre de cet article, nous verrons comment mettre en œuvre l'intégration et la livraison en continu avec TeamCity, Bitbucket et Microsoft Azure.

Pour cet article, nous allons utiliser :

• TeamCity : développé par l'éditeur JetBrains, TeamCity est un serveur d'intégration continue basé sur la plateforme Java. Il est accessible gratuitement et grâce à son interface Web épurée, il est assez facile à configurer et à utiliser. Vous pouvez télécharger TeamCity à l'adresse suivante : https://www.jetbrains.com/teamcity/download/ ;
• Bitbucket est un système de contrôle de version reparti, maintenu par Atlassian. La solution est basée sur Git et est également disponible gratuitement pour les petites équipes d'au plus cinq personnes ;
• Microsoft Azure : la plateforme Cloud de Microsoft offre de nombreux services, dont l'hébergement pour les applications Web.

TeamCity n'offre pas une prise en charge native de Bitbucket. Pour utiliser ce dernier avec votre serveur de CI, vous devez étendre ses fonctionnalités via l'installation d'un plugin. Il existe plusieurs plugins pour TeamCity permettant une intégration avec Bitbucket.

Ceux-ci offrent quasiment les mêmes fonctionnalités et reposent sur une API publique publiée d'Atlassian. Cette API offrir une meilleure prise en charge de l'intégration continue dans Bitbucket. Ainsi, tout développeur est en mesure d'étendre son serveur d'intégration continue pour prendre en charge Bitbucket.

Grâce à cette API, vous n'aurez plus besoin de vous connecter à votre serveur de CI  pour avoir le statut d'une build, pour savoir si vos tests ont réussi ou échoué, etc. Vous avez directement ces informations à partir de votre gestionnaire de code source.

 Pendant mes recherches, j'ai trouvé les plugins suivants pour TeamCity :

• Teamcity Commit Status Publisher qui est développé par JetBrains (éditeur de TeamCity). Il peut être téléchargé avec son code source sur GitHub ;
• TeamCity - Stash integration qui est maintenu par un développeur tiers et dont le code est disponible en open source sur GitHub ;
• Bitbucket Pull Requests Plugin, également développé par un tiers et disponible en téléchargement sur GitHub.

Dans le cadre de cet article , nous allons nous limiter à l'utilisation de « TeamCity Commit Status Publisher ». Mon choix s'est porté sur ce dernier parce qu'il est maintenu par JetBrains. De ce fait, nous sommes quasiment sûrs que ce dernier évoluera avec les mises à jour de TeamCity. Ce qui n'est pas forcément le cas avec les autres plugins.

De plus, en dehors de Bitbucket, « TeamCity Commit Status Publisher » offre également une prise en charge de :

• JetBrains Upsource ;
• GitHub ;
• GitLab ;
• Gerrit Code Review tool.

III-A. Installation du plugin « TeamCity Commit Status Publisher »▲

La procédure d'installation standard d'une extension TeamCity est suffisante pour ajouter « TeamCity Commit Status Publisher ». Vous devez :

1. Télécharger le Zip de « TeamCity Commit Status Publisher » ;
2. Arrêter votre serveur TeamCity ;
3. Copier le Zip dans le répertoire « plugins » du dossier d'installation de TeamCity ;
4. Redémarrer votre serveur.

Le Zip sera automatiquement dézippé et installé dans votre instance TeamCity au redémarrage du serveur. Vous pouvez vérifier que le plugin est correctement installé à partir de la liste des plugins disponibles dans votre instance.

Si vous disposez déjà d'un projet TeamCity avec des builds configurées, passez directement à l'étape suivante. Toutefois, vous devez vous rassurer que la section « Branch Specification » est renseignée dans votre VCS (version control systems) Root.

La création d'un projet et la configuration d'une build sont assez simples avec TeamCity.

Pour un projet hébergé dans un gestionnaire de sources distant comme c'est le cas avec Bitbucket, vous pouvez simplement renseigner l'URL de votre repository, et TeamCity se chargera automatiquement de récupérer certaines informations liées au projet.

Pour le faire, allez sur Projets, ensuite sur Administration, puis cliquez sur « Créer un projet à partir de l'URL » :

Dans la fenêtre qui va s'afficher, renseignez l'URL de votre repository dans un format qui est supporté par TeamCity, puis les paramètres d'authentification (nom d'utilisateur et mot de passe) :

Après avoir cliqué sur le bouton « Proceed », TeamCity va se connecter à votre repository et récupérer les informations concernant le projet, dont certaines seront affichées dans la fenêtre suivante, permettant la création du projet et de votre première build :

Un clic sur « Proceed » va lancer la création du projet et des paramètres de configuration de la build associée. TeamCity va analyser votre repository et vous proposer automatiquement un « Build Steps » pour votre projet :

Cochez ce dernier et cliquez sur « Use selected » afin que ces modifications soient prises en compte.

Pour permettre à TeamCity de publier le résultat de votre build à Bitbucket, vous devez configurer la section « Branch Specification » de votre « VCS Root ».

À ce stade, vous pouvez exécuter votre build. Vous remarquez que vous avez désormais des détails sur la branche exécutée.

IV-A. Configuration de la publication des résultats de build sur Bitbucket ▲

La prochaine étape sera la configuration d'une « Build Features », qui sera utilisée par TeamCity pour publier le résultat de votre build sur Bitbucket.

Pour le faire :

• allez dans la section « Build Features » des paramètres de configuration de votre build, puis cliquez sur « Add Build feature » ;
• cliquez sur la liste déroulante « Choose Build Feature » et choisissez « Commit statuts publisher » ;
• dans la zone « Choose publisher », sélectionnez « Bitbucket Cloud » ;
• renseignez votre nom d'utilisateur et votre mot de passe ;
• cliquez sur « Save » pour enregistrer.

Exécutez une build de votre projet.

Ouvrez Bitbucket, et vous verrez le résultat de votre build dans la liste de de vos commits :

Et en cliquant sur chaque build, vous avez un résultat plus détaillé, vous permettant par la même occasion de valider l'exécution des tests unitaires.

IV-B. Automatisation des builds▲

À ce stade, nous sommes en mesure de lancer une opération de build à partir de TeamCity. Cette opération effectuera la compilation et l'exécution de tests de notre branche. Ensuite le statut de la build sera publié sur Bitbucket. Cependant, cette opération se fait manuellement en cliquant chaque fois sur le bouton « Run ». Le but de l'intégration continue est de permettre une build automatique du projet avec une exécution des tests unitaires dès qu'un commit est effectué.

Dans cette section nous verrons comment rendre cette opération automatiquement. Ainsi, chaque fois qu'un nouveau commit sera effectué, l'opération de build de votre projet se fera automatiquement.

Pour mettre cela en place, il faudra créer un « Build Trigger ». Ce dernier est une règle qui permet de procéder à l'initialisation d'une nouvelle build suite à un certain évènement (nouveau commit, chaque matin à 6h, etc.)

Pour créer un nouveau trigger :

• cliquez sur le bouton « Triggers » dans la zone « Build Configuration Settings » ;
• cliquez sur le bouton «  Add new trigger » ;
• dans la liste déroulante, choisissez « VCS Trigger ». Ce trigger permet de lancer une opération de build, lorsqu'un changement a été détecté dans le système de contrôle de versions (VCS Root) qui a été défini dans les paramètres de configuration de la build ;
• cliquez sur « Save » pour procéder à la création du trigger.

Désormais, chaque fois qu'un changement sera effectué au niveau de votre système de contrôle de versions, une opération de build sera automatiquement lancée.

Dans une démarche d'industrialisation du développement, on ne peut pas parler d'intégration continue sans évoquer le déploiement continu (CD, continuous delivery).

Mais, avant de déployer, nous devons d'abord créer un package de notre application.

La première chose à faire, c'est de vous assurer que Microsoft Web Deploy est installé sur le serveur sur lequel est disponible TeamCity. Sinon, procédez à l'installation de ce dernier.

V-A. Création d'un profil de publication▲

Dans Visual Studio, ouvrez votre solution, puis faites un clic droit sur votre projet dans l'explorateur de solutions et cliquez sur « Publier » dans le menu contextuel qui s'affiche.

Dans la fenêtre qui s'affiche :

• cliquez sur « Personnaliser » dans la zone « Sélectionner une cible de publication » ;
• entrez le nom du profil de publication dans la fenêtre qui s'affiche et cliquez sur le bouton « Ok » ;
• dans la fenêtre qui s'affiche, déroulez la zone « Publish method » et sélectionnez « Web Deploy Package » ;
• dans la zone de saisie « Package location », saisissez « $(SolutionDir)\artifacts\webdeploy\Integration\TeamCityTest.zip » ;
• cliquez sur suivant, puis choisissez la configuration (Release ou Debug) ;
• puis cliquez sur « Fermer », ensuite acceptez l'enregistrement des modifications qui ont été apportées à votre profil de publication.

Un fichier avec l'extension « pubxml » sera créé dans le dossier « Properties/PublishProfiles » de votre projet.

 

Sélectionnez

<?xml version="1.0" encoding="utf-8"?>
<!--
Ce fichier est utilisé par le processus de publication/package de votre projet Web. Vous pouvez personnaliser le comportement de ce processus
en modifiant ce fichier MSBuild. Pour en savoir plus à ce sujet, consultez la page http://go.microsoft.com/fwlink/?LinkID=208121. 
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <WebPublishMethod>Package</WebPublishMethod>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <SiteUrlToLaunchAfterPublish />
    <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <DesktopBuildPackageLocation>$(SolutionDir)\artifacts\webdeploy\Integration\TeamCityTest.zip</DesktopBuildPackageLocation>
    <PackageAsSingleFile>true</PackageAsSingleFile>
    <DeployIisAppPath>TeamCityTest</DeployIisAppPath>
    <PublishDatabaseSettings>
      <Objects xmlns="" />
    </PublishDatabaseSettings>
  </PropertyGroup>
</Project>

Commitez les modifications que vous avez apportées à votre projet. Avec ce nouveau profil de publication, lorsque TeamCity procédera à la compilation de votre application, un package de déploiement sera généré et sauvegardé dans le répertoire que vous avez mentionné. La zone « Artifacts » dans la liste des résultats de vos builds permettra désormais de voir les fichiers de déploiement qui ont été générés.

Mais, pour cela, vous devez apporter quelques modifications aux paramètres de configuration de votre build.

V-B. Modification des paramètres de build pour prendre en compte le déploiement▲

Revenez dans TeamCity. Ouvrez la page de configuration des paramètres de votre build. Dans le menu à gauche, cliquez sur « General Settings » et saisissez « artifacts\webdeploy\Integration=>Webdeploy » dans la zone « Artifact path » :

Ce chemin doit être celui que vous avez défini précédemment dans les paramètres de votre profil de publication. Enregistrez les modifications.

Cliquez sur « Build Steps » dans le menu, puis modifiez votre Build Steep « Visual Studio (sln) ».

Dans la zone « Command line parameters », saisissez les informations suivantes et enregistrez les modifications :

 

Sélectionnez

/p:DeployOnBuild=True 
/p:PublishProfile="PackageIntegration"
/p:ProfileTransformWebConfigEnabled=False

• /p:DeployOnBuild=True permet de signaler que vous souhaitez qu'un package soit généré à chaque build de votre application dans TeamCity ;
• /p:PublishProfile="PackageIntegration" est le profil de publication qui sera utilisé. Celui que vous avez créé précédemment ;
• /p:ProfileTransformWebConfigEnabled=False permet de désactiver la transformation du fichier de configuration (WebConfig). En principe, la transformation se fait par WebDeploy.

Désormais, si vous procédez à la build de votre application dans TeamCity, vous verrez comme artifacts vos fichiers de déploiement :

Désormais, vous êtes prêt pour le déploiement.

Maintenant que nous sommes en mesure de générer un package de déploiement de notre application à chaque build, il est maintenant question de procéder au déploiement de ce dernier sur Azure.

Pour cela, nous allons ajouter une nouvelle « Build Configuration » a notre projet. Pour éviter d'avoir à refaire certaines configurations, nous allons utiliser les paramètres de la précédente « Build Configuration », pour notre nouvelle « Build Configuration ». Pour le faire :

• depuis la page d'administration de votre build dans TeamCity ;
• cliquez sur le bouton Actions puis sur « Copy Configuration » ;
• dans la fenêtre qui s'affiche, entrez le nom de la « Build Configuration » ;
• cliquez sur Ok, pour enregistrer les modifications.

Nous allons apporter quelques changements à cette nouvelle « Build Configuration » que nous avons créée.

La première chose à faire sera l'ajout d'une dépendance avec la « Build Configuration » précédente. L'objectif est de permettre de lancer la tâche de déploiement uniquement après que l'étape de build se soit effectuée correctement.  Pour le faire :

• cliquez sur « Dependencies » ;
• puis sur « Add new snapshot dependency » ;
• dans la fenêtre qui s'affiche, sélectionnez votre build ;
• et cliquez enfin sur Save.

Pour garder une certaine cohérence dans la numérotation des builds, vous allez modifier les paramètres généraux de votre build et éditer la zone « Build number format » pour saisir « %dep.NomdeVotreProjet_NomDeVotreBuild.build.counter% ».

En procédant ainsi, vous serez en mesure d'identifier quelle build a été déployée, et de ce fait le commit en rapport avec cette dernière.

Vous allez ensuite supprimer le trigger qui a été repris de la configuration précédente. S'il reste actif, à chaque modification de votre repository, le déploiement se fera automatiquement après la build. En fonction de votre stratégie de déploiement continue, vous pouvez bien évidement décider de maintenir ce trigger.

Passons maintenant à la création de la « Build Step » qui permettra le déploiement de votre application dans Azure. Revenez sur la page de votre « Build Configuration », cliquez sur « Build Steps » dans le menu à gauche. Cliquez ensuite sur « Add build step ». Dans la fenêtre qui va s'afficher :

• sélectionnez « Command Line » dans la zone « Runner type » ;
• renseignez le champ « Step name » ;
• saisissez les informations suivantes dans la zone de saisie « Custom script » :

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:package='artifacts\WebDeploy\Integration\TeamCityTest.zip' -dest:auto,computerName="https://teamcitytest.scm.azurewebsites.net:443/msdeploy.axd?site=teamcitytest",userName="userName",password="pwd",authtype="Basic",includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension

Pour récupérer les informations nécessaires à la création de votre profil de publication, vous pouvez :

• vous connecter au portail Microsoft Azure ;
• accéder à la liste des « App Services » ;
• sélectionner votre application Web ;
• cliquer sur « Obtenir le profil de publication » dans la boite d'outils pour télécharger les informations sur votre profil de publication.

Cela fait, pour lancer le déploiement de votre application, vous pouvez simplement vous positionner sur la dernière build qui s'est effectuée avec succès, puis cliquer sur Actions, ensuite sur Promote :

Puisque nous avons mentionné que notre « Build Configuration » de déploiement dépend de cette build, TeamCity affichera dans une fenêtre le nom de la build de déploiement. Vous n'aurez plus qu'à cliquer sur Run pour lancer le déploiement.

En fonction de vos environnements (par exemple : Dev, Préprod, Prod) vous pouvez créer plusieurs « Build Configuration » de déploiement. Par exemple, si vous disposez d'un Serveur Azure pour les développeurs, vous devez créer une « Build configuration » pour les déploiements qui dépendra de la « Build Configuration » de l'intégration continue. Le déploiement pourrait se faire automatiquement sur le serveur de développement. Ensuite, pour les testeurs, vous allez créer une « Build configuration » qui dépendra de la « build configuration Dev ».

Lorsque votre application sera prête pour la préproduction, vous allez simplement promouvoir la build correspondante dans la « build configuration Dev ».

Cet article s'appuie sur l'expérience acquise lors du virage vers le DevOps dans un projet. L'exploitation à bon escient des outils qui entrent en œuvre dans l'industrialisation du développement réside dans l'adoption d'une bonne stratégie de DevOps, adaptée au contexte du projet.

Nous avons décrit dans cet article les différents outils, configurations et approches pour la mise en place de l'intégration et la livraison en continu. Ce dernier pourra être utilisé comme base par des équipes, afin de définir leur stratégie d'industrialisation du développement de leur application.

Je tiens à remercier Malick SECK pour sa relecture orthographique.

• La documentation officielle de TeamCity  ;
• La documentation officielle de Bitbucket  ;
• La documentation officielle de Microsoft Azure .