Intégration et déploiement continu dans Azure depuis VSO

L’intégration et le déploiement continu sont des processus qui consistent à récupérer les sources à partir d’un référentiel de sources commun, à les compiler et à exécuter les tests unitaires (intégration continue), mais aussi à déployer l’application (déploiement continu) à chaque archivage de modifications de sources.

Ce processus doit pouvoir être testable et automatisable.

Nous allons voir ici comment mettre en place ces processus avec Visual Studio Online (VSO) comme contrôleur de source et un site web dans Azure pour environnement de déploiement.

L’outil qui nous permettra l’exécution de ce processus est une build vNext qui est le nouveau système de build mis place récemment par Microsoft.

Prérequis : VSO et Azure website

Le contrôleur de sources utilisé est VSO dans lequel un projet est créé et les sources sont archivées.

Ce projet contient une application web ainsi que plusieurs projets de tests unitaires.

L’environnement de destination (de déploiement) est un site web dans Azure.

Création d’un Endpoint dans VSO

Pour le déploiement dans Azure, la build TFS à besoin de connaître les informations du compte Azure. Pour cela, nous allons créer une liaison entre notre projet VSO et notre abonnement Azure.

Dans les paramètres du projet VSO, se rendre dans l’onglet Services, puis, cliquer sur “New Service Endpoint” et choisir Azure.

Dans la fenêtre qui s’affiche, cliquez sur le lien bas “publishsettings xml file” pour télécharger un fichier xml de configuration.

Ce fichier contient la liste des abonnements Azure (de l’utilisateur connecté) avec leur clé de certificats.

Copier l’id et la clé de certificat dans la fenêtre.

Nous avons maintenant tous nos éléments pour créer notre build.

Création de la build vNext

Une build vNext correspond au nouveau système de build mis en place par Microsoft dans TFS afin de remplacer les builds faites en XAML.

Ce système de build a été complètement refondu. Parmi les nouveautés, nous pouvons notamment citer :

• La création d’une définition de build ne se fait plus avec du xaml et workflow foundation, mais via une interface graphique.
• Toutes les modifications d’une définition de build sont historisées.
• La gestion d’une définition de build ainsi que la file d’attente se font uniquement via le team web access.

Les builds vNext sont disponibles sur Visual Studio Online et TFS 2015. Passons maintenant à la création de la définition build.

La gestion des builds se fait par l’onglet Build du projet. La création d’une définition de build se passe en deux étapes : le choix d’un template puis la sélection des étapes du processus et leur configuration.

La 1ère étape de la création consiste à choisir le template qui comportera les étapes pour notre build.

Dans notre cas, on choisira dans “déployment” , le modèle “Azure Website” qui contient par défaut toutes les étapes nécessaires pour une intégration et déploiement dans un site Azure.

La 2ème étape permet, quant à elle, de choisir et de paramétrer les étapes de la build.

Si l’on veut une simple intégration et déploiement, le paramétrage est déjà presque complet par défaut.

Regardons les principales étapes :

• La compilation

Tout est déjà pré-rempli, reste à choisir la version de Visual Studio.

La plateforme et la configuration sont des variables déjà remplies dans l’onglet “variables”

• Les tests

Le paramétrage est déjà pré-rempli avec les valeurs par défaut d’exécution de tests.

• Le déploiement dans Azure :

Cette étape nécessite un peu de paramétrage.

Il faut remplir :

• La souscription azure qui correspond au EndPoint créé précédemment.
• Le nom du Web Site Azure.
• La localisation du Web Site.

Voila les principales étapes sont paramétrées, reste à configurer le trigger, c’est à dire le déclencheur, qui pour notre cas est une intégration continue.

Une fois tout configuré, il faut sauvegarder, mettre un titre et un commentaire qui servira pour l’historique.

Un petit tour dans l’historique.

Test de la build

Pour tester le bon fonctionnement de notre build, il suffit de faire une modification dans un des fichiers de la solution puis d’archiver (ou de faire un push pour git).

Une fois l’archivage effectué, nous devrions voir qu’une nouvelle build a été créée et lancée.

Si tout se passe bien, cette build va récupérer et compiler les sources, elle exécutera les tests unitaires et, seulement si toutes ces étapes se déroulent correctement, elle déploiera dans le site web de Azure.