Centre de déploiement et DevOps Project

Pour mon test dans le précédent article, j’avais besoin de créer et déployer rapidement dans Azure une WebAPI.

Deux possibilités !

J’ai créé le projet sous Visual Studio, je l’ai publié sur Azure. Si je veux ensuite gérer le projet sous Azure DevOps (VSTS ) je peux utiliser le module Centre de déploiement de la Web Application. J’obtiens alors très simplement une configuration de build et release pour le déploiement vers Azure et je n’ai plus qu’a pousser mon code sur le dépôt créé :

4 - Centre de déploiement et DevOps Project

5 - Centre de déploiement et DevOps Project

6 - Centre de déploiement et DevOps Project

Pour déployer dans Azure, j’aurais pu également utiliser Azure DevOps Project !

3 - Centre de déploiement et DevOps Project

Cette outils permet depuis Azure et sans besoin préalable de :

  • Créer une Web Application du langage / framework de votre choix.
  • Créer un projet et un repository git dans VSTS
  • Configurer CI et CD.

Cet outils est très facile à utiliser, il suffit de quatre étapes pour générer un pipe d’intégration et de déploiement continue vers Azure.

2 - Centre de déploiement et DevOps Project

Il ne reste plus qu’a récupérer le code source créée par Azure DevOps en se connectant au repository pour pouvoir commencer à travailler. Notre configuration de builds et de releases est déjà opérationnelle.

A l’heure actuelle, février 2019, Azure DevOps Project s’enrichit :

7 - Centre de déploiement et DevOps Project

Pour les projets basés sur le Framework Core nous pouvons générer le code, et le pipeline CI/CD en quelques clics pour les solutions :

  • WebApplication Windows ou Linux
  • WebApp conteneurisé avec Docker
  • Fonction pour faire du serverless
  • Service Fabric pour du microservices made in Microsoft
  • Kubernetes Service pour du microservices managé via K8s.

Pour tester un nouveau produit, il n’y a rien de plus facile !

Thomas

Application Service Fabric dans Visual Studio 2017

Hello !

Suite à la création de notre cluster Service Fabric dans Azure, nous allons aujourd’hui détailler la création de notre projet dans Visual Studio 2017.

Création du projet

Tout d’abord il faut configurer le poste du développeur pour utiliser les templates de projets  ASF. Pour télécharger et installer le SDK rendez vous ici : https://docs.microsoft.com/fr-fr/azure/service-fabric/service-fabric-get-started

Nous pouvons maintenant créer notre projet Cloud de type Application Service Fabric :

1 - Application Service Fabric dans Visual Studio 2017

Nous devons ajouter un premier service à notre projet :

2 - Application Service Fabric dans Visual Studio 2017

Pour bien comprendre les différents type de service (au delà du framework .Net utilisé) que nous pourrons héberger dans notre cluster, je vous invite à consulter ce lien.

Pour faire simple nous pouvons retenir :

  • Service sans état : service “classique” ou les données sont stockés dans une source de connées externe (base de données, fichier xml).
  • Service avec état : le service conserve des données qui sont répliquées entre chaque instance du service grâce aux types Reliable. Ainsi si un client tente d’accéder à une donnée du service, peu importe l’instance qui est appelée, la donnée sera la même.

Je choisis le type de projet ASP .Net Core que je veux implémenter comme pour un projet .Net Core classique :

3 - Application Service Fabric dans Visual Studio 2017

Si par la suite je veux ajouter un nouveau projet à mon application il faudra faire clic droit sur notre projet principal et Ajouter > Nouveau Service Service Fabric pour que ce nouveau projet sois lié à notre environnement ASF.

4 - Application Service Fabric dans Visual Studio 2017

On voit ici que la différence majeure entre un service ASP .Net Core standart et un service ASP .Net Core dans Service Fabric c’est le projet par défaut créé par Visual Studio (ici Orange.Techs.Microservices).

Celui-ci contient des fichiers de configurations pour le build et déploiement de nos services dans un cluster Service Fabric. En revanche nos services en eux mêmes (ici Orange.Techs.Microservices.StatelessAPI) sont identiques aux services de type WebApi que nous connaissons déja !

Par conséquent vous retrouvez facilement vos habitudes de développement au niveau des services ! Un point plus que positif à prendre en compte pour l’adoption de cet environnement 🙂

Azure Web App Deployment Slots

Hello !

Un sujet d’actualité aujourd’hui, suite au récent rachat de GitHub par Microsoft, avec la configuration d’un pipe DevOps à partir d’un projet GitHub et en bonus la présentation des slots de déploiement Azure.

Nous allons donc brancher VSTS sur un projet de mon dépôt GitHub.

On commence par créer un nouveau projet :

1 1 - Azure Web App Deployment SlotsInitialisation du dépôt :

2 1 - Azure Web App Deployment Slots

Sélectionner Build and Release > Build > New pipeline et choisir GitHub 🙂

3 1 - Azure Web App Deployment Slots

Il s’agit toujours d’un projet ASP.NET Core :

4 1 - Azure Web App Deployment Slots

On pense à décocher “Publish Web Projects” qui ne concerne pas le type de projet WebAPI :

5 1 - Azure Web App Deployment Slots

Et on lance une build !

6 1 - Azure Web App Deployment Slots

Nous pouvons maintenant configurer notre Release. Build and Release > Release > New definition. Nous allons choisir un template un peu différent de ce que nous avons déjà testé jusqu’a présent !

7 1 - Azure Web App Deployment Slots

Je relie ma release à ma build :

8 1 - Azure Web App Deployment Slots

Je met en place le déploiement continu :

9 1 - Azure Web App Deployment Slots

Petite pause dans la configuration VSTS, nous devons également paramétrer notre Web App Azure !

Je choisis de créer une Web App et je remplis les informations habituelles :

10 1 - Azure Web App Deployment Slots

Une fois ma Web App créée je vais paramétrer un emplacement de déploiement. Ceux-ci sont bien utiles quand il s’agit d’avoir à disposition un environnement de test iso à la production. Ces emplacements de déploiements sont des “sous applications”  appartenant au même service plan que votre Web App.

11 1 - Azure Web App Deployment Slots

J’ajoute un environnement “preprod” identique à la production :

12 1 - Azure Web App Deployment Slots

J’ai désormais deux environnements à ma disposition, donc deux URL. La deuxième étant taggé avec le suffixe “preprod” qui correspond au nom de mon slot :

13 1 - Azure Web App Deployment Slots

Et ma Web App de production :

14 1 - Azure Web App Deployment Slots

Je peux vérifier que mes deux Web Apps sont fonctionnelles :

15 1 - Azure Web App Deployment SlotsPassons à la configuration de ma release !

Je remplis comme d’habitude Azure Subscription, le nom de ma Web App et du groupe de ressource associé mais je dois en plus choisir sur quel slot déployer mon application !

16 1 - Azure Web App Deployment Slots

Je choisis dans un premier temps de déployer sur preprod :

17 2 - Azure Web App Deployment Slots

Je pense à modifier le package à déployer :

19 1 - Azure Web App Deployment Slots

Et je vais désactiver la deuxième étape du déploiement. Cette étape effectue un échange entre ces deux environnements, mais ici je ne veux pas que ce swap soit fait automatiquement …

21 1 - Azure Web App Deployment Slots

Ma release est prête !

22 1 - Azure Web App Deployment SlotsJ’effectue une demande de déploiement :

23 1 - Azure Web App Deployment Slots

Release en cours !

24 1 - Azure Web App Deployment Slots

J’ai des informations détaillée sur le déploiement via l’onglet Logs :

25 1 - Azure Web App Deployment Slots

Une fois le déploiement terminé, j’obtiens sur mon environnement “preprod” :

26 1 - Azure Web App Deployment Slots

Mon application est donc opérationnelle sur cet environnement !

Sur l’URL “prod” en revanche :

15 1 - Azure Web App Deployment SlotsRien n’a changé ! C’est ce que nous voulons. Nous avons donc une version N-1 en production et une version N en preprod.

Je peux donc valider tranquillement le fonctionnement de mon API REST. En cas d’erreur, ma production n’est pas impactée et je peux apporter mes modifications. Une fois que tout est testé / vérifié / validé nous pouvons échanger nos environnements.

je retourne sur ma Web API :

27 1 - Azure Web App Deployment Slots

Et je clique sur le bouton Échanger à droite du bouton Arrêter. Je n’ai plus qu’un clic à faire pour swapper entre mes deux environnements !

28 1 - Azure Web App Deployment Slots

Ma preprod est maintenant devenu la prod et inversement. Mon environnement de preprod contient maintenant la version N-1 de mon application tendis que la prod est en version N.

30 1 - Azure Web App Deployment Slots

En cas d’anomalie détectée un peu tard, je n’ai qu’a reproduire l’opération pour que mes utilisateurs récupèrent immédiatement la version N-1 de l’API !

Dernier sujet aujourd’hui, la fonctionnalité “Test en production”. Reprenons notre déploiement de tout à l’heure avec :

  • En preprod : version N
  • En prod : version N-1

Je peux grâce à cette fonctionnalité orienter un certain volume du trafic utilisateur vers la version de preprod à la place de la production. Ainsi un certain pourcentage des utilisateurs vont pouvoir tester en condition réelle la nouvelle version de l’API. Une fois que le test me semble concluant, je peux procéder au swap !

29 1 - Azure Web App Deployment Slots

Récapitulons les avantages de ces emplacements de déploiements :

  • Pas d’intéruption de service pendant un déploiement. Tout est transparent pour l’utilisateur.
  • Possibilité de tester sur un emplacement dans les mêmes conditions que la production. Quand les tests sont validés, on opère le swap des environnements.
  • Possibilité de rediriger progressivement le flux des utilisateurs pour tester la nouvelle version et vérifier qu’elle répond correctement à l’augmentation du trafic réseaux.
  • Suite au swap, l’emplacement “preprod” contient la version qui était en production. Ainsi, en cas d’anomalie un rollback est facile à opérer.

Cette notion de deployment slot est une mise en oeuvre concrète des patterns “Blue/Green Deployment” et “Canary Release“. Je vous laisse suivre les liens pour une approche plus théorique du sujet 🙂

Azure DevOps Project

Hello !

Après avoir vu dans un précédent article comment mettre en œuvre un process d’intégration et déploiement continu via VSTS nous allons voir comment Azure nous permet de déployer tout ça automatiquement avec Azure DevOps Project.

Dans cet article nous allons, depuis Azure et sans la moindre ligne de code, générer :

  • Un projet ASP .Net Core MVC
  • Un pipe CI / CD (intégration et déploiement continue) dans VSTS
  • Une Web Application Azure
  • Bonus : notre site web s’exécutera dans un conteneur Docker

Nous pouvons commencer ! Direction le portail Azure puis “Créer une ressource” et choisir “DevOps Project” :

1 2 - Azure DevOps Project

Je choisis le framework .Net Core :

2 2 - Azure DevOps Project

J’indique que je veux déployer mon application dans une Web App avec support de conteneurs. On peut également choisir une Web App classique Windows ou Linux :

3 3 - Azure DevOps Project

Dernière étape je sélectionne mon compte Team Services et un nom de projet ainsi qu’un tenant Azure et le nom de ma Web App :

4 4 - Azure DevOps Project

Création en cours …

5 2 - Azure DevOps Project

Déploiement réussi !

6 1 - Azure DevOps Project

Nous retrouvons bien notre groupe de ressources (dont le nom à été défini par Azure) contenant notre Web App DevOpsExemple :

7 1 - Azure DevOps Project

Détails :

8 1 - Azure DevOps Project

Si je clique sur l’URL renseignée … Success !!

16 2 - Azure DevOps Project

Voyons maintenant ce qui a été créé côté VSTS :

9 1 - Azure DevOps Project

Dans Code > Files je retrouve un projet de base ASP .Net Core MVC :

10 1 - Azure DevOps Project

Dans la section Commit je retrouve la création du projet par Azure :

11 1 - Azure DevOps Project

Dans l’onglet Build je retrouve une définition de build (étonnant !) :

12 1 - Azure DevOps Project

13 2 - Azure DevOps Project

Cette build contient deux étapes de commandes Docker pour construire puis déployer dans Azure mon image Docker. Pour se faire c’est le fichier Dockerfile présent dans le dépôt qui est utilisé.

14 1 - Azure DevOps Project

Dans la section Release je trouve : 15.5 - Azure DevOps Project

Et un pipe d’exécution depuis ma build :

15 1 - Azure DevOps Project

Bref on retrouve ici tout ce qu’on a vu et créé manuellement dans le dernier tutoriel 🙂

Récupérons le code ! On ouvre un nouveau Visual Studio > Team Explorer > Gérer les connexions > Connexion à un projet :

17 2 - Azure DevOps Project

On choisit son dossier :

18 1 - Azure DevOps Project

Et on obtient notre code source avec notre fameux Dockerfile !

19 2 - Azure DevOps Project

Ce fichier contient les instructions pour générer et déployer notre projet dans un conteneur Docker :20 1 - Azure DevOps Project

Dans ce Dockerfile les instructions vont :

  • Indiquer que je vais utiliser l’image aspnetcore-build:1.1 fourni par Microsoft pour compiler mon application dans le dossier de base “app”.
  • Je vais exécuter les commandes Restore puis Publish pour compiler mon projet et enregistrer les dll dans app/out.
  • Enfin je construis mon image Docker depuis l’image de base aspnetcore:1.1 dans laquelle je pousse mes dll.

Je fais un petit correctif sur la page d’accueil de notre site afin de vérifier notre pipe de déploiement vers Azure !

21 1 - Azure DevOps Project

On commit en local :

22 1 - Azure DevOps Project

On synchronise avec le serveur :

23 1 - Azure DevOps Project

Une nouvelle build se déclenche :

24 1 - Azure DevOps Project

En cours …

25 1 - Azure DevOps Project

Suite à cette build c’est au tour de la Release de s’exécuter :26 1 - Azure DevOps ProjectEn cours …

27 1 - Azure DevOps Project

Et notre site web est à jour !

28 1 - Azure DevOps Project

Et c’est déjà terminé !

Vous pouvez donc, en quelques clics, générer automatiquement depuis Azure un pipe d’intégration et de déploiement continu avec VSTS pour un projet .Net ou .Net Core, avec ou sans Docker 🙂

Microsoft Visual Studio Team Services

Hello !

Maintenant que nous avons développé notre Web API et que nous l’avons déployée sur Azure dans une Web App, nous allons configurer l’intégration et le déploiement continu de notre projet dans VSTS.

ArticleVsts Alm - Microsoft Visual Studio Team Services

VSTS et DevOps

J’ai effectué une présentation de cet outil dans le précédent article, n’hésitez pas à le consulter pour une vision plus globale.

Nous allons ici plutôt nous concentrer sur la mise en œuvre !

Configuration de notre projet dans VSTS

Tout d’abord nous devons créer notre projet dans VSTS. Après vous être identifié sur teamservices vous pourrez créer un nouveau compte pour héberger vos projets.

4 3 1 - Microsoft Visual Studio Team Services

Création de votre compte :5 1 - Microsoft Visual Studio Team ServicesJe choisis Git comme gestionnaire de code source.

6 - Microsoft Visual Studio Team Services

J’ai désormais accès à l’interface VSTS pour gérer mes projets depuis l’URL : thomasrannou.visualstudio.com. Par défaut un projet existe déjà.

8 - Microsoft Visual Studio Team ServicesCréons un nouveau projet pour héberger notre application !

9 - Microsoft Visual Studio Team Services

Je choisis d’initialiser mon répertoire avec un README.

10 - Microsoft Visual Studio Team Services

C’est terminé, mon répertoire est disponible et n’à plus qu’a accueillir mon code source.

11 - Microsoft Visual Studio Team Services

Maintenant je dois connecter mon projet VSTS à mon Visual Studio 🙂

Ouvrir un nouveau Visual Studio. Puis Team Explorer > Gérer les connexions (l’icône verte en forme de prise) > connexion à un projet.

Sélectionnez votre compte puis votre projet créé précédemment.

13 1 - Microsoft Visual Studio Team Services

Visual Studio vous propose alors un répertoire sur disque ou stocker votre projet.

14 - Microsoft Visual Studio Team Services

Modifiez-le si besoin et “Cloner”. Puis vous devrez copier dans ce répertoire C:\W\WebAppExempleAzure votre solution .Net :

  • WebAppExemple
  • WebAppExemple.Model
  • WebAppExemple.sln

Vous pourrez alors ouvrir normalement votre solution et y apporter des modifications. Il n’y a plus qu’à archiver tout ça !

En local :

57 - Microsoft Visual Studio Team Services

Il faut d’abord “Indexer” les nouveaux fichiers.

58 - Microsoft Visual Studio Team Services

Puis “Valider les changements intermédiaires” :

59 - Microsoft Visual Studio Team Services

On synchronise sur le serveur …

16 1 - Microsoft Visual Studio Team Services

La synchronisation permet de “Push” (pousser) sur le serveur nos modifications et de “Pull” (tirer) en local les modifications versionnées par d’autres développeurs dans le cadre de projet d’équipes. Ici forcément, je n’ai pas grand chose à récupérer 🙂

17 - Microsoft Visual Studio Team Services

Une fois qu’on a cliqué sur Synchroniser un message nous confirme que notre répo local est en phase avec le serveur.

18 - Microsoft Visual Studio Team Services

Pensez bien à exclure les dossiers bin et obj de vos modifications à archiver : clic droit puis “Ignorer ces éléments locaux”. Ces dossiers n’ont pas besoin d’être versionnés et ne feront qu’alourdir votre dépôt.

Si vous connaissez Git rien ne vous surprend la dedans. Si ce gestionnaire de source ne vous est pas familier vous serez étonné par le double push, d’abord en local, puis sur le serveur, mais c’est tout à fait normal. Avec Git les modifications sont d’abord validées localement avant d’être envoyées sur le serveur. Pour savoir l’essentiel de git c’est par ici.

Je peux maintenant visualiser mon code versionné depuis l’onglet “Code” > Files de VSTS. Dans la section “Commits” je pourrais voir tous les Push effectué sur ce dépôt.

19 - Microsoft Visual Studio Team Services

Maintenant que nous avons notre code source dans notre répertoire , il nous reste à configurer une build et une release vers Azure 🙂

Sélectionner Build and Release > Build > New pipeline

20 - Microsoft Visual Studio Team Services

On indique notre projet courant et la branche de travail. Ici il s’agit du master puisque nous n’avons pas créé d’autre branche. Pour un vrai projet on ne développera pas sur le master mais sur des branches de développement issues de celle-ci. Voir GitFlow !

21 - Microsoft Visual Studio Team Services

Je vais utiliser le template de projet .Net Core.

22 - Microsoft Visual Studio Team Services

Ce template de build est très simple et permet de compiler une solution .Net Core et de générer un fichier zip contenant les dll du projet.

Je renomme également ma build au passage :

23 - Microsoft Visual Studio Team Services

Pensez à décocher “Publish Web Projects” qui ne convient qu’au projet ASP .NET Core MVC.

24 - Microsoft Visual Studio Team Services

Cliquez alors sur “Save And Queue” pour enregistrer notre définition et lancer une build. Je peux alors préciser l’ID du commit que je veux lier a cette build  (que j’ai récupérée en parallèle).

26 - Microsoft Visual Studio Team Services

Build en cours…

27 - Microsoft Visual Studio Team Services 28 - Microsoft Visual Studio Team Services

Lorsque la build est terminée, en cas de succès et d’échec vous recevrez un mail de notification :

29 - Microsoft Visual Studio Team Services

Nous pouvons maintenant configurer notre Release. Build and Release > Release > New definition

30 - Microsoft Visual Studio Team Services

Je choisis un template de déploiement Azure Application.

Ici le template choisis est le plus simple possible mais il est possible de sélectionner des templates plus évolué permettant de :

  • Paramétrer automatiquement Insights.
  • Basculer des slots de déploiement : utile pour la mise en oeuvre du blue/green deployment.
  • Effectuer des tests de charge.
  • Executer des scripts powershell avant de pousser les dll.
  • etc …

Bien sur la release se base sur un template mais peut être enrichis par la suite sans problème pour répondre à de nouveaux besoins.

48 - Microsoft Visual Studio Team Services

Je donne un nom à mon environnement de travail :

49 - Microsoft Visual Studio Team Services

On sélectionne le build que l’on veut lier à cette release via “Add artifact” :

32 - Microsoft Visual Studio Team Services

Je peux ensuite cliquer sur “1 phase, 1 task” pour configurer ma release.

Je renseigne mon ID Azure et la Web App d’hébergement de mon application :

50 1 - Microsoft Visual Studio Team Services

Je modifie les propriétés de mon déploiement :

56 1 - Microsoft Visual Studio Team Services

Sélectionner le zip WebAppExemple dans la séction “Package or folder” :

53 - Microsoft Visual Studio Team Services

Je vais indiquer maintenant dans la section “Continuous deployment trigger” que chaque build provoque une release et donc un déploiement.

54 - Microsoft Visual Studio Team Services

On note que l’on peut préciser des conditions aux déploiements en cliquant sur la zone colorée ci-dessous :

55 - Microsoft Visual Studio Team Services

On peux alors configurer des déploiements qui dépendront par exemple :

  • D’une heure ou d’un jour
  • D’une approbation préalable d’un utilisateur

Voyons maintenant ce qu’il se passe si je modifie mon code ! Je vais ajouter une propriété Ville à mon Client et j’archive.

38 1 - Microsoft Visual Studio Team Services

Je synchronise sur le serveur à nouveau …

39 - Microsoft Visual Studio Team Services 40 - Microsoft Visual Studio Team Services

Une build se lance automatiquement !

42 - Microsoft Visual Studio Team Services

En cours …

43 - Microsoft Visual Studio Team Services

Et suite à la build, une release se déclenche également !

44 - Microsoft Visual Studio Team Services

En cours …

Capture - Microsoft Visual Studio Team Services

Une fois ces deux étapes terminées, si je retourne sur le contrat swagger de ma WebApp je retrouve bien ma nouvelle propriété Ville 🙂

47 - Microsoft Visual Studio Team Services

Et c’est finis pour aujourd’hui ! Nous avons en fin de compte une API .Net Core déployée dans une WebApp Azure, monitoré via Application Insights avec un pipe DevOps géré sur VSTS ! Pas mal pour gérer sans encombre son projet perso 😉

Azure App Service

Aujourd’hui, nous allons déployer notre Web API ASP .Net Core dans Azure. A la fin de ce tutoriel, vous aurez publié votre API dans une Web App Azure et configurer le monitoring avec Application Insights.

Je vais utiliser comme base le projet créé dans le dernier article, que vous pouvez récupérer ici : GitHub.

Dans un premier temps, nous devons paramétrer Application Insights dans notre solution :

1 - Azure App Service

2 - Azure App Service

Je précise que mon compte Azure est déjà créé et renseigné dans Visual Studio. Pour créer un tenant Azure : https://azure.microsoft.com.

A noter que si vous possédez un compte MSDN vous disposez gratuitement de crédit Azure renouvelé chaque mois.

Pour activer ce crédit : https://my.visualstudio.com

3 1 - Azure App Service

On renseigne le nom du groupe et de la ressource Insights à créer :

4 1 - Azure App Service

Un écran récapitulatif nous présente les ressources crées automatiquement dans Azure :

5 - Azure App Service

Ce paramétrage réalisé automatiquement consiste à ajouter à notre solution un fichier de configuration et à créer dans Azure une ressource Insights, chargée de logger et surveiller notre application.

Maintenant que notre application est paramétrée nous allons la déployer dans le Cloud et la rendre accessible de tous !

Sur notre projet, clic droit puis “Publier” :

6 - Azure App Service

On déploie dans une App Service, hébergée sur Windows ou Linux, à votre convenance !

7 - Azure App Service

La aussi, on renseigne le nom de notre application et le groupe de ressource auquel elle appartiendra. Un groupe de ressource est en quelque sorte un dossier virtuel qui contiendra nos éléments Azure. Un groupe de ressource est affecté à une localité d’hébergement.

8 1 - Azure App Service

On doit également choisir un plan d’hébergement. Celui-ci dépend des ressources matérielles que l’on veux avoir à notre disposition. Ce plan d’hébergement se traduira par une facturation différente suivant la puissance CPU / RAM choisie.

9 1 - Azure App Service

Il n’y a plus qu’à cliquer sur Créer :

10 1 - Azure App Service

Une fois le déploiement terminé, une page web s’ouvre sur l’URL de notre application.  Ajoutez “/swagger/” à la fin de cette URL pour retrouver une interface familière.

11 - Azure App Service

Une fois que votre Web API est déployé, Application Insights vous offre la possibilité de surveiller votre programme.

Depuis le portail Azure sélectionnez votre ressource Insights pour un accès à un ensemble de fonctionnalités :

    • Suivi d’indicateurs : latence, volumétrie des données, trafic réseaux, nombre d’erreurs …
    • Métriques en temps réel
    • Appels effectués sur votre API
    • Outils de création de graphe personnalisé
  • Langage de requête (LinQ) pour extraire les données qui vous semblent intéressante.

Énormément de possibilités pour un outils extrêmement puissant !

13.5 1 - Azure App Service

14 - Azure App Service

Pour en profiter pleinement, une mise à jour du package NuGet d’Insights s’impose !

13 - Azure App Service

Après avoir redéployé notre application :

19 - Azure App Service

Vous pourrez accéder à l’écran Flux de métriques en temps réel sur le portail Azure.

15 - Azure App Service

Pour découvrir l’étendue des possibilités de ce formidable outils : https://docs.microsoft.com/fr-fr/azure/application-insights/app-insights-visual-studio

En apparté, voici un petit outils pour tester vos API : Postman

Il vous permettra très facilement de tester vos API, et de pouvoir enreigstrer vos tests dans une collection pour pouvoir les reutiliser facilement !

16 - Azure App Service 17 - Azure App Service 18 1 - Azure App Service

Dans le prochain tuto, nous utiliserons Azure DevOps entre Visual Studio 2017 et notre WebApp Azure pour automatiser les builds et les déploiements !

Web API ASP.NET Core

Après la partie théorique, place à la pratique !

Dans cet article, nous allons détailler comment créer une Web API en utilisant un template de projet ASP .NET Core et le framework .NET Core.

A la fin du tutoriel vous aurez développé une API REST en .NET Core présenté par Swagger. J’utilise Visual Studio 2017 pour mes développements (v15.6.6  actuellement).

Démarrer Visual Studio 2017 et sans plus attendre :

1 - Web API ASP.NET Core

Puis :

2 - Web API ASP.NET Core

On voit ensuite que l’on va utiliser le framework .Net Core 2.0, dernière version stable actuellement, et créer un projet de type API.

3 - Web API ASP.NET Core

Visual Studio nous prépare notre solution que je nomme WebAppExemple :

4 - Web API ASP.NET Core

Sélectionnez maintenant “WebAppExemple” à la place de IIS Express comme ci-dessous. Ainsi votre exécution ne dépendra plus de IIS et votre projet sera auto-hebergé grâce au composant Kestrel de .Net Core :

5 1 - Web API ASP.NET Core

6 - Web API ASP.NET Core

Votre WEB API est désormais accessible en local sur le port 8299 !

Notre ControllerValues n’étant pas des plus utiles, je vais maintenant créer une classe d’entité métier et son API !

Première étape, création d’un projet WebAppExemple.Model dans notre solution :

7 - Web API ASP.NET Core

On y ajoute une classe Client. Client représente une entité métier dans notre modèle de donnée.

8 - Web API ASP.NET Core

Pour gérer notre modèle justement, je vais utiliser Entity Framework Core. Ce framework est un ORM (Object Relational Mapping) et permet comme son nom l’indique de faire le lien entre des classes C# (logique objet) et une base de données relationnelles (SGBDR comme SQLServer).

Dans l’explorateur de solution, clic droit sur notre projet Model et sélectionnez “Gérer les packages Nuget…”, vous obtiendrez cet écran :

9 - Web API ASP.NET Core

Recherchez EntityFrameworkCore et installez le ! Nous pouvons maintenant créer une nouvelle classe de type DbContext pour gérer notre modèle de donnée. Notre entité ContexteExemple contiendra une collection d’entités Clients :

10 - Web API ASP.NET Core

Avant de pouvoir aller plus loin, je dois ajouter une dépendance entre mes deux projets. Via le gestionnaire de références, j’ajoute une dépendance dans WebAppExemple :

10.5 - Web API ASP.NET Core

Pour pouvoir utiliser notre ContexteExemple, il faut déclarer cette classe en tant que Service. Cela se passe dans la classe Startup, méthode ConfigureServices. Cette méthode permet de gérer l’injection de dépendance de notre projet.

Très brièvement l’injection de dépendance (IoC) permet de gérer un catalogue des types abstrait (interfaces) lié à leurs implémentation. Le conteneur d’IoC permettra d’obtenir pour chaque type abstrait, l’implémentation correspondante.

Pour une présentation plus complète du sujet, je vous invite à lire cet article très complet : developpez.com

Pour qu’à l’exécution, la classe ContexteExemple puisse être utilisée, je dois la déclarer via la méthode AddDbContext comme ci-dessous :

10.6 - Web API ASP.NET Core

Je déclare ici que notre base de données sera uniquement “In Memory”. Il n’y aura donc pas de BDD physique comme SQLServer ou SQLite.

A présent que notre entité Client est créée et gérée au sein d’un contexte de donnée, nous avons besoin d’une API pour exposer les opérations CRUD à réaliser sur cette entité : Create / Read / Update / Delete.

Pour se faire, clic droit sur notre dossier Controllers, Ajouter, Contrôleur puis :11 - Web API ASP.NET Core

On déclare que notre Contrôleur permet de gérer notre entité Client au sein de notre ContexteExemple :

12 - Web API ASP.NET Core

On obtient alors une classe ClientsController prête à l’emploi contenant toutes les méthodes de base. Ces méthodes que je vous laisse découvrir manipule des objets Clients en lecture / écriture / modification et suppression, dans un contexte EntityFramework géré en mémoire.

Bien sur vous pouvez enrichir votre API en rajoutant les fonctionnalités de votre choix sur notre entité Client !

A noter le constructeur de notre classe ClientsController :

18 300x123 - Web API ASP.NET Core

Grace à l’injection de dépendance un ContexteExemple sera instancié automatiquement à l’appel de ClientsController.

A l’exécution de notre projet, on notera qu’une nouvelle URL est accessible : http://localhost:8299/api/clients ! Cependant en l’état son utilisation est peu évidente ! Pour répondre à ce problème, une solution : Swagger !

Premièrement ajoutons à notre projet WebAppExemple les dépendances nécessaires :

13 - Web API ASP.NET Core

En ce moment votre projet devrait ressembler à ceci :

14 - Web API ASP.NET Core

Je dois maintenant configurer l’utilisation de Swagger dans nos méthodes Configure et ConfigureServices :

15 - Web API ASP.NET Core

La méthode Configure demande de générer la documentation Swagger en JSON et d’utiliser SwaggerUI pour la présenter. Dans ConfigureServices je dois enregistrer mon service Swagger en lui précisant la version de notre API, ainsi que le titre.

Je vous invite maintenant à lancer votre application et accéder à l’url http://localhost:8299/swagger/   et ….

16 - Web API ASP.NET Core 17 - Web API ASP.NET Core

Cet outils nous permet plusieurs choses :

  • Pouvoir visualiser facilement les opérations accessibles de notre API.
  • Partager facilement une documentation entre les développeurs.
  • Pouvoir tester facilement nos méthodes via l’interface générée.

Je vous laisse tester nos différentes méthodes et vous verrez que l’on peut gérer la création (POST), la modification (PUT), la suppression (DELETE) et la lecture (GET) de nos clients !

Le code source de ce tutoriel est disponible sur GitHub.