Aujourd’hui, nous sommes ravis d’annoncer le SDK Azure 2.8.1 pour Visual Studio 2013 et Visual Studio 2015. Cette mise à jour du SDK offre de nouvelles fonctionnalités intéressantes pour les développeurs Azure App Service. Elle s’ajoute à la nouvelle version d’App Service API Apps et à la disponibilité générale du SDK Mobile Apps pour les serveurs .NET. Avec ces services et outils mis à jour qui font suite aux mises à jour récentes apportées à ASP.NET 5 RC, c’est le moment idéal pour développer des applications web, mobiles et d’API REST dans Azure. Cette publication résume les nouvelles fonctionnalités publiées dans le SDK Azure 2.8.1.

SDK Azure 2.8.1 pour .NET
[Télécharger pour VS 2015 | VS 2013]

• Nouvelle expérience de création App Service moderne : nous avons repensé l’ensemble des outils App Service et unifié les expériences de création et de publication d’applications pour les développeurs d’applications web, mobiles et d’API.
• Mises à jour des modèles de projet pour les applications API et mobiles : Pour aider les développeurs qui souhaitent utiliser les mises à jour récentes pour les développeurs d’applications mobiles et d’API REST, nous avons mis à jour les modèles Visual Studio.
• Exportation de modèle Resource Manager : les nouveaux outils permettent d’exporter des fichiers JSON en un clic pour les ressources que vous allez créer afin de pouvoir recréer vos topologies dans d’autres groupes de ressources, voire d’autres abonnements Azure.
• Génération améliorée du client de l’API REST : simplification de l’expérience utilisateur et améliorations de la génération de code sous-jacentes fournies par le générateur Swagger open source de l’équipe du SDK Azure, connu sous le nom de AutoRest.

Unification de l’expérience de développement App Service dans Visual Studio

De très nombreuses fonctionnalités App Service sont partagées par chaque type de ressource, notamment l’identité mobile qui intègre une ressource plus largement disponible et la fonctionnalité de définition d’API qui devient disponible partout. C’est pourquoi nous avons décidé que l’expérience de développement App Service devait se modéliser de la même façon. Une application web peut utiliser les nombreuses API REST hébergées dans le même groupe de ressources, pour être complétée par la suite par une application mobile. Comme il y aura bien évidemment toujours des nouveautés dans App Service, nous unifions l’expérience de publication et fournissons une vue bien plus simple de la publication de vos applications web, mobiles et d’API sur App Service.

Une interface utilisateur repensée, informative et fonctionnelle avec davantage d’options

Nous avons également accompli d’énormes progrès dans l’apparence générale de l’expérience proposée par les outils App Service. Nous sommes heureux d’illustrer ces nouvelles améliorations de l’interface utilisateur qui constituent la première vague de l’énorme effort de réingénierie que nous avons produit au sein de l’équipe chargée des outils App Service. À l’occasion de cette première vague de reconception, nous avons faisons évoluer le design pour refléter les nouveaux concepts de l’interface utilisateur de Visual Studio, comme les services connectés et les nouveaux outils Office. Sous la nouvelle interface utilisateur se cache une multitude d’améliorations en matière de code et d’ajustements pour rendre la mise en avant de nouveaux services plus efficace pour les partenaires et les clients. Dans les prochaines publications, vous découvrirez la nouvelle extensibilité offerte par les outils Azure. Mais pour l’instant, jetons un coup d’œil au nouveau design amélioré des expériences de sélection et de création d’applications.

Faciliter le choix de l’application

L’un des problèmes remontés par des clients et collègues qui publient de nombreuses applications sur Azure était que la liste était difficilement gérable et qu’il était de plus en plus difficile de « deviner » ou de savoir quelle application devait servir de destination. Nous nous sommes inspirés du design de Cloud Explorer pour fournir à la fois des affichages de groupes de ressources et des affichages de types de ressources, ce qui facilite le regroupement de vos applications dans la boîte de dialogue « Sélectionner ».

Si le regroupement n’est pas suffisant en raison du grand nombre de cibles de publication potentielles dans votre abonnement, nous avons ajouté une fonctionnalité intéressante : la recherche. Vous pouvez à présent taper votre requête de recherche dans la boîte de dialogue afin de filtrer les applications correspondant à votre terme. La recherche est également rémanente. Par conséquent, si vous effectuez une recherche puis changez d’affichage pour passer des groupes de ressources aux types de ressources, la recherche est conservée et seules les correspondances sont visibles. Vous pouvez ainsi plus facilement trouver votre cible de publication dans la liste des ressources de votre abonnement.

Nouvelles mises à jour apportées à la création App Service

La plus grande évolution permettant d’optimiser l’expérience de création App Service est sans doute le processus de création et de provisionnement des applications. La nouvelle boîte de dialogue, illustrée ci-dessous, offre de nombreux signaux visuels affichant les opportunités disponibles pendant la création de l’application. Nous avons conservé toutes les fonctionnalités d’hébergement importantes sur le premier onglet de l’expérience à deux onglets. Si vous avez simplement besoin d’une nouvelle application dans le cloud et que vous disposez déjà d’un groupe de ressources et d’un plan d’hébergement que vous souhaitez utiliser pour votre nouvelle application, le processus est simple, il suffit de cliquer sur Créer dans la boîte de dialogue de création App Service.

Si vous avez besoin d’un nouveau plan App Service, la création d’un plan se fait en un clic via le bouton Nouveau. Dans l’écran Plan App Service, vous pouvez créer un plan d’une des nombreuses tailles disponibles dans le portail.

Si vous souhaitez créer un groupe de ressources dans lequel publier votre application, entrez-le simplement dans la zone de liste déroulante Groupes de ressources. Ensuite, la boîte de dialogue vous fournit de nombreux signaux visuels pour vous indiquer que vous allez créer un groupe de ressources. L’indicateur sous forme d’icône bleu sous l’onglet Hébergement reflète le même message.

Création de services supplémentaires dont votre application peut avoir besoin

Le deuxième onglet du nouveau écran de création App Service vous permet de sélectionner les services supplémentaires dont votre application peut avoir besoin. Dans cette version, nous assurons la prise en charge des bases de données et des serveurs SQL dans le processus de création App Service. Toutefois, vous n’êtes pas limité à une seule base de données. Vous pouvez créer autant de serveurs SQL ou de bases de données que nécessaire, directement dans la boîte de dialogue.

Bien que SQL soit le seul fournisseur publié pendant la période d’utilisation du SDK 2.8.1, nous avons effectué quelques tâches d’ingénierie majeures pour activer cette boîte de dialogue. Nous avons notamment créé un modèle extensible dans lequel les équipes partenaires peuvent travailler pour étendre la mise en avant de leurs services. Nous avons créé un prototype d’expérience de mise en avant du provisionnement Redis dans cette même boîte de dialogue, ainsi que quelques discussions avec les équipes Azure Key Vault et Document DB. À l’avenir, vous pourrez installer des extensions pour cette expérience (et profiter des mises à jour fréquentes ou par abonnement à partir de l’intégration de la Galerie d’extensions Visual Studio dans Visual Studio).

Exporter votre topologie Azure pour qu’elle puisse être utilisée afin de créer des environnements miroirs

Lorsque vous évoluez dans la boîte de dialogue de création App Service en configurant et en ajoutant des services, chaque ressource que vous ajoutez est affichée dans la zone de révision de l’onglet Hébergement initial. Ce « panier de ressources » fournit un instantané de toutes les ressources que vous allez créer dans votre abonnement.

À mesure que vous augmentez le nombre de ressources ajoutées à votre panier, le modèle JSON Azure Resource Manager est créé dynamiquement et ajouté en mémoire. Lorsque vous êtes certain d’avoir ajouté dans votre panier toutes les ressources dont votre application a besoin pour fonctionner, cliquez sur le bouton Exporter et indiquez l’emplacement où vous souhaitez enregistrer le modèle JSON représentant tout ce qui se trouve dans votre panier. Vous pouvez ensuite utiliser les modules Azure PowerShell pour exécuter votre modèle dans un autre groupe de ressources, ou même dans un autre abonnement Azure. Cette fonctionnalité est idéale pour les clients disposant de modèles reproductibles représentant leurs topologies d’application, car ils n’ont pas besoin de modifier ni de configurer manuellement les modèles à la main. Si vous avez besoin de personnaliser davantage la topologie, les fonctionnalités intégrées de l’éditeur de modèle Resource Manager publiées précédemment s’intègrent parfaitement, puisque les fonctionnalités de modification de modèle reconnaissent le schéma JSON dans le fichier JSON exporté.

Mises à jour des modèles de projet App Service

Pour prendre en charge les nouvelles modifications apportées aux ressources API et Mobile, nous avons mis à jour les modèles Visual Studio pour qu’ils tirent parti des nouvelles améliorations dans les domaines de fonctionnalités.

Amélioration des modèles d’application mobile

App Service Mobile permet de créer facilement des applications mobiles qui fonctionnent avec des données hors connexion, authentifient les utilisateurs et envoient des notifications Push. Nous venons d’annoncer la prise en charge en disponibilité générale du SDK serveur .NET Mobile Apps, qui vous permet de créer une application dans App Service qui sert ces fonctionnalités, ainsi que la logique personnalisée, pour vos clients mobiles. Avec cette version, nous mettons actuellement à jour la prise en charge de la création et de la gestion d’un projet d’application mobile dans Visual Studio. Pour commencer, ouvrez la boîte de dialogue Nouveau projet à partir de Fichier > Nouveau projet. Développez ensuite Modèles > Visual C#, puis sélectionnez « Web ». Choisissez « Application web ASP.NET », indiquez le nom du projet, puis cliquez sur OK. Sous Modèles ASP.NET 4.5.2, sélectionnez Application mobile Azure.

Cliquez sur OK. Votre application est créée et s’affiche dans l’Explorateur de solutions. Le modèle doit sembler familier aux clients qui utilisent Mobile Apps ou Mobile Services. La principale différence que vous avez peut-être remarqué tient dans la configuration. Le modèle configure maintenant tout ce qui se passe au démarrage de OWIN et vous donne un contrôle plus granulaire sur les composants qui sont et ne sont pas ajoutés.

Le projet représente une application de liste de tâches simple. Les clients mobiles peuvent consommer des données stockées dans SQL via TodoItemController, dérivé de TableController. TableController traduit les API compatibles avec les mobiles en opérations CRUD qui peuvent être comprises par le backend de données de votre choix (dans ce cas, SQL). Il adhère également au contrat hors connexion, ce qui vous permet de commencer immédiatement à tirer parti des fonctionnalités de synchronisation hors connexion de Mobile Apps. Vous pouvez ajouter d’autres contrôleurs de table ou contrôleurs d’API compatibles avec les mobiles en cliquant avec le bouton droit sur le dossier « Contrôleurs » et en sélectionnant Ajouter > Contrôleur. Sélectionnez ensuite Contrôleur de table Azure Mobile Apps ou Contrôleur personnalisé Azure Mobile Apps et suivez l’Assistant pour créer votre point de terminaison.

Une fois que votre projet est prêt, vous pouvez le publier sur App Service à l’aide de la nouvelle boîte de dialogue Publier, comme décrit précédemment dans l’article. Les applications mobiles sont à présent prises en charge en tant que cible de publication de niveau supérieur dans le menu des options de la boîte de dialogue de création App Service.

Amélioration des modèles d’application API

Le modèle d’application API a évolué depuis sa première préversion. Depuis, les clients nous ont appris que le débogage local était important. Celui-ci est donc à présent activé dans le nouveau modèle API Apps. Ce modèle donne une structure globale plus simple, avec moins de dépendances sur les modèles de gestion des ressources ou fichiers propres à la passerelle d’application API. Le modèle API Apps est fondamentalement un modèle d’API web, avec l’ajout du package NuGet open source Swagger qui porte le nom de Swashbuckle. Nous avons également inclus les modifications précédentes apportées au fichier SwaggerConfig.cs afin que l’interface utilisateur Swagger soit désactivée par défaut. Nous avons également inclus le filtre d’opération qui améliorait notre approche de la génération d’ID d’opération Swagger. Apprenez-en davantage sur les personnalisations Swashbuckle sur Azure.com.

Améliorations de la génération d’API REST

À l’instar des investissements réalisés par les équipes App Service comme API Apps et Gestion des API en relation avec l’utilisation de Swagger, nous continuons nos efforts concernant la génération de code basée sur les métadonnées Swagger exposées par API Apps. En cliquant sur la plupart des projets C# dans Visual Studio et en sélectionnant Ajouter > Client d’API REST, la boîte de dialogue simplifiée du générateur client de l’API REST s’affiche. Cliquez sur le bouton Parcourir pour accéder à la boîte de dialogue « Sélectionner App Service », où vous pouvez sélectionner n’importe quel App Service dont le point de terminaison de définition d’API est défini.

Résumé

Si vous n’avez pas encore de compte Azure, vous pouvez vous inscrire à un essai gratuit et commencer à utiliser toutes les fonctionnalités décrites ci-dessus dès aujourd’hui. Visitez ensuite le Centre de développement Azure pour en savoir plus sur la façon de créer des applications. Veuillez soumettre les bogues via Connect, les suggestions via UserVoice et les réflexions ou idées via Send-a-smile dans l’IDE Visual Studio. Cette version est une première étape dans la direction que nous souhaitons donner aux outils App Service. Nous sommes de ce fait impatients de recevoir vos commentaires, de savoir quels services vous souhaitez voir apparaître dans le panier des ressources et que vous nous aidiez à fournir un développement d’applications plus rationalisé en continuant à donner votre avis. Pour obtenir des détails ou connaître les problèmes connus liés à cette version du SDK, consultez la page Notes de publication Azure SDK 2.8 et 2.8.1. 

Crédits

Ce billet de blog a été rédigé à plusieurs. Un grand merci à Matthew Henderson et tous les collègues qui ont travaillé dur sur cette version.