Blog de Hinault Romaric (.NET Core, ASP.NET Core, Azure, DevOps)

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 anomalies 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 version. 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 continue avec TeamCity, Bitbucket et Microsoft Azure.

Présentation des outils

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.

Support de Bitbucket dans TeamCity

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 ce billet de blog, 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.

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 disponible dans votre instance.

Configuration de votre Build

Si vous disposez déjà d’un projet TeamCity avec des builds configurés, 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 source distant comme c’est le cas avec Bitbucket, vous pouvez simplement renseigner lURL 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 ».

NB : Ceci devrait marcher uniquement pour Bitbucket Cloud (la version online de Bitbucket). Pour Bitbucket Server, cette information est différente. La commande « git ls-remote » devrait vous aider à savoir ce qu’il faut mettre comme information dans cette section.

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

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.

Automatisation des builds

A 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 ». Un « Build Trigger » 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 version (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 version, une opération de build sera automatiquement lancée.

Dans le prochain billet, nous verrons comment configurer le déploiement continu.