Pull Requests avec Visual Studio 2017, VSTS & GIT

Lors du précédent article, nous avons démontrer une approche de développement Agile avec Git et Visual Studio 2017. Pour compléter cette expérience, nous allons regarder dans le présent article comment avec VSTS et Visual Sudio le développeur va pouvoir valider la qualité de ses développement au travers du processus de Pull Request.

Suite au dernier article, nous avons développé une fonctionalité de calcul de Discount, le code a été commité localement puis poussé sur le serveur via un Push.

C'est à ce moment précis qu'intervient tout le processus qualité au travers de l'intégration continue et des Pull Requests. Pour rappel, l'objectif d'un Pull Request est de proposer du code poussé au travers d'une feature branche pour promotion au merge dans la branche master.
Définition : Une Pull Request est un process collaboratif qui permet au reste de l'équipe de discuter des changements dans une feature branch et valider le merge vers master une fois que tout le monde à approuvé.

ETAPE 1 - Configuration préliminaire pour les Pull Requests

La première chose à faire est de préparer son Repo pour la gestion des Pull Requests

Afin de procéder à la revue de la Pull Requests, il faut d'abord que le code présenté passe au travers d'un "Quality Gate", nous allons utiliser pour cela une Build. Nous créeons à cet effet une build suffixée PR (pour Pull Request) qui sera utilisée pour la validation des Pull Requests, pour cela nous clonons simplement la Build Master CI qui est notre build d'intégration continue standard pour notre branche master.

Le point suivant va consister à configurer les Branch Policies de notre Repository, à partir de l'onglet Code / Version Control, choisir la branche master du Repo et cliquer sur l'onglet Branch Policies comme montré ci dessous

La première configuration consiste à demander l'exécution de la build dédiée pull Request afin de s'assurer que le Reviewer va inspecter du code qui passe le minimum qualité imposé à savoir que le code compile, les tests passent et l'analyse automatique de code est OK. Tous ces points sont portés par le workflow de la build.

Il faut s'assurer également que la Pull Request est bien reliée à un PBI et dans notre exemple, que la Pull Request ne peut pas être validée par la personne qui a poussé le changement, également que la Pull request ne pas être complétée si le reviewer l'a rejetée 

Il suffit simplement de sauvegarder cette configuration

ETAPE 2 - Création et Validation d'une Pull Request

Une Pull Request peut être crée par le développeur à partir de Visual Studio. Après avoir poussé ses changements sur le serveur, il suffit de naviguer dans l'onglet Branches du Team Explorer, se positionner sur la feature branch, dans notre exemple Discount et lancer la commande Create Pull Request

On est alors redirigé sur l'instance web de VSTS, il suffit alors de compléter la description de la Pull Request, selectionner le ou les reviewers et valider la création

On peut voir en bas de page le code modifié / ajouté / supprimé

Suite à la création, on est redirigé  vers la page de statut de la Pull Request, et en parallèle la build a été lancée

Le point très interessant au niveau des Pull requests est notamment la discussion qui peut être initée directement dans le code inspecté, ci dessous après avoir activé l'onglet Files, on peut voir le thread de discussion inité

Il est interessant également de regarder le contenu des onglets Updates et Commits pour le détail

Enfin si tout est OK du point de vue du Reviewer, il reste à approuver la Pull Request : 

Ce qui va déclencher une build de validation du merge, et dernière étape, il va falloir Compléter la Pull request, si la build n'est pas terminée, c'est indiqué dans le haut de la boite de dialogue.

Dès que la build est terminée, on peut complèter le merge

Au final, on a l'affichage du détail montrant l'achèvement avec succès de la Pull Request

On notera que nous avons demandé la suppression de la feature branch suite au merge et également un Squash des changements qui consiste à condenser l'historique des changements réalisés dans la feature branche (nous n'avons plus tout le détail), comme montré ci dessous

Développement Agile avec Visual Studio 2017, VSTS & GIT

Avec la montée en puissance des méthodes Agiles et de Git, la manière d'approcher les développements pour les développeurs "modernes" change radicalement, par exemple alors qu'en mode conventionnel on va recommander de limiter le nombre de branches, avec Git, chaque nouveau développement va entrainer la création d'une Feature Branch à partir d'une story, et également le démarrage ne va plus se faire à partir du code mais à partir du Backlog, ce qui veut dire que le développeur va tirer une nouvelle branche directement à partir du PBI ou User Story à développer. Cette nouvelle approche a été totalement intégrée en terme d'ergonomie à VSTS, et c'est ce que l'on va démontrer dans cet article. Nous allons partir sur le développment d'un PBI

Ci dessous le PBI exemple 

Cliquer le menu contextuel et selectionner la commande New Branch

 

Pour la branche, une bonne convention est d'entrer feature/Nom_de_la_fonction, ce qui permettra de générer une structure avec sous dossier dans Git comme on le verra un peu plus tard

Après avoir cliqué sur Create Branch, la fenêtre Code s'affiche et l'on voit apparaitre la nouvelle branche Discount dans le dossier Feature

Pour démarrer les développements, démarrer Visual Studio, procéder à une Synchronisation à partir de Team Explorer, 

Puis cliquer sur l'onglet Branches pour accèder à l'arbre des branches locales et remote

On voit bien la branche Discount du dossier feature parmi les autres branches. En revanche la branche n'est pas présente en local, pour cela il faut simplement faire un Check out

 Le Checkout peut se faire par le menu contextuel comme montré ci dessous

La branche locale apparait instananément dans le dossier feature local

A noter dans la barre d'état, on peut naviguer dans les différentes branches du repo git local et également voir le nombre de commits non poussés sur le serveur

 

Puis le développeur procéde au développemnent puis Commit ses changements, qui sont à ce stade local

On voir ci dessous le nombre de commits en attente, en cliquant simplement sur l'icone, on est redirigé vers la fenêtre de synchronisation 

 il suffit de cliquer sur Push afin de pousser les changement coté serveur.

 Une confirmation est renvoyée pour l'opération

L'étape suivante consiste normalement à créer une Pull Request, ce qui sera l'objet du prochain Post

VSTS et Déploiement automatisé de bases de données avec DACPAC

Dans le précédent article nous avons vu l'avantage et la simplicité de mise en oeuvre de projets de bases de données DACPAC. Nous allons voir comment intégrer simplement dans nos processus d'intégration continue et déploiement continu nos développements de bases de données.

Notre projet DACPAC est donc sous controle de code source Git sous VSTS dans notre exemple.

La première étape va consister à créer une Build permettant de compiler et générer en sortie le fichier DacPac et le profile de publication de manière à ce qu'il puisse être consommé par une Release du module Release Management dont la responsabilité sera de déployer le package fabriqué par la build sur un instance SQL Azure dans notre exemple

Pour la création de la build, il s'agit d'une Build Standard à laquelle nous allons rajouter deux taches de copies, une pour le fichier Dacpac et une pour le fichier de publication

Ci dessous la structure de la build avec l'ajout de deux taches "Copy Files"de la librairie standard

La configuration des taches de copies est pour Dacpac: cette tache va copier dans la Drop location dans un sous dossier database le fichier Dacpac du projet de base de données

Pour le fichier de publication nous avons : ce fichier se trouve généralement à la racine du projet et va contenir les informations pour la mise à jour de la base de données.

Pour vérifier que la build fonctionne correctement, il suffit simplement de la lancer, une fois terminée afficher les détails de la build et cliquer sur l'onglet Artifacts : 

Cliquer sur le bouton Explore à droite de Drop, les deux fichiers doivent être présents dans le dossier Database

La build fabrique bien le package nécessaire à Release Management pour déployer les modifications effectuées sur la base de données.

L'étape suivante va consiter à créer une Release Definition permettant de déployer ce package sur une instance SQL Azure dans notre exemple, pour cela accèder à l'onglet Release et cliquer sur le bouton New Definition

Configurer le projet et la build à utiliser pour le déploiement puis cliquer sur Create

Etant donné que nous avons un compte SQL admin pour le déploiement, nous pouvons définir des variables pour le compte et le mot de passe pour le déploiement comme montré ci dessous (penser à utiliser le cadenas pour passer ces données en secret!)

Pour la partie environnment, renommer en Dev par exemple puis rajouter une tache de déploiement  : Azure SQL Database Deployment , cliquer sur Add puis Close

La dernière étape va simplement consister à configurer le déploiement : 

Le prérequis est d'avoir provisionné un Service Endpoint de type Azure Resource Manager pour votre projet VSTS afin de permettre à la release definition de communiquer avec la ressource Azure cible, comme montré ci dessous : 

Puis procéder à la configuration comme montré  ci dessous : 

Une fois la configuration terminée, il ne reste plus qu'à tester, pour cela, nous allons rajouter un champ Description dans la table Countries, archiver le code, ce qui va lancer la Build automatiquement et provisionner le package, ci dessous la table modifiée:

La build est alors déclenchée, lorsque terminée, nous lançons une release : 

 Puis simplement configurer la build à utiliser (noter qu'en cas de déploiement auto, on peut configurer l'utilisation de la dernière build) puis cliquer sur Create

Le déploiement est alors en progression

Au bout de quelques minutes, la release est déployée

Si l'on se connecte à l'instance cible avec le server Explorer de Visual Studio par exemple, on verra que la colonne Description a bien été créée dans la table Countries de la base de données cible

Nous avons donc vu que l'intégration des développements de base de données s'intégraient de manière simple sur l'ensemble du cycle de vie de développement tel qu'exposé par VSTS et nous permet d'inscrire nos développements de base de données dans une démarche Devops.

Quick Start avec les projets de bases de données - Visual studio 2017 et DACPAC

Le code SQL permettant de développer des bases de données, au travers de schémas, function SQL et Procédures stockées doivent à l'instar du code applicatif être intégré dans le cycle de vie du développement notamment au travers de la création de solutions et projets de bases de données, mise sous controle de code source de l'ensemble des artefacts de code, intégration au processus d'intégration continue et également déploiement continu. Au travers de ce premier article, nous allons démontrer comment utiliser Visual studio 2017 avec les projets DACPAC et également VSTS et Git pour développer une base de données. Dans l'article suivant nous verrons comment Déployer notre base de données au travers du pipeline de release.

La première consiste à créer un projet DacPac, pour cela démarrer Visual Studio 2017 taper Ctrl Shift N pour créer un nouveau projet, sélectionner  le Type SQL Server puis le template SQL Server Database Project, nommer le projet et valider

Puis nous allons tout simplement dans notre cas importer le schéma d'une base de données existante afin de la modifier, pour cela  à partir du menu contextuel, lancer la commande Import / Database...

Cliquer sur Select Connection, dans notre exemple, il s'agit d'un base SQL Azure; simplement complèter les informations de connection puis cliquer sur Connect

Configurer les options d'import puis cliquer sur Start

L'import est visualisé dans la fenêtre Summary, cliquer sur Finish lorsque terminé

 Le projet de base de données apparait dans l'explorateur de solution, pour modifier / consulter un objet, il suffit simplement de l'ouvrir

On peut travailler soit en mode Designer ou via le code SQL directement

Nous allons à titre d'exemple rajouter un champ nommé description dans la table Categories

Le projet étant sous controle de code source et donc susceptible d'être modifié par un ou plusieurs développeurs, l'outil de comparaison de Schéma va permettre de visualiser les différences entre le projet et la base de données cible. A noter que cet outil de comparaison peut également comparer deux bases de données. A l'aide du menu contextuel, lancer la commande Schema Compare

La référence pour la source sera le projet de base de données, il faut juste définir la cible, pour cela, selectionner l'option Select Target

Un assistant permet de choisir simplement la base de données cible

Après avoir cliqué sur le bouton Compare, les différences entre la source et la cible sont affichées, on peut savoir par les icones s'il s'agit de suppression, ajouts ou modifications.

Enfin le bouton Update peut permettre au développeur de mettre à jour la cible directement

A partir de Visual Studio, en utilisant la vue Server Explorer, il est possible de voir la structure de la base de données cible, dans notre cas SQL Azure, on obtient l'affichage suivant  ou l'on remarque que le nouveau champ Description n'existe pas encore : 

On va pouvoir également utiliser la commande Publish à partir du menu contextuel du projet

*

Simplement préciser les informations de connection puis cliquer sur Publish

On peut suivre le déroulement de la publication 

Finalement, on raffraichit la vue de la base de données à partir du Server Explorer, on constate que le champ a bien été modifié

 Dans le prochain article, nous verrons comment intégrer ce Publish dans notre pipeline de release