Build 2019 – Jour 1

20190506_104437

De retour avec un article portant sur la conférence Build de Microsoft encore cette année. Avec beaucoup de plaisir, j’ai la chance d’y assister en direct de Seattle avec plusieurs collègues.

La première journée a été marquée par plusieurs annonces importantes au niveau d’Azure et de .NET. Voici ce que j’ai retenu de cette première journée de conférence.

Azure Keynote

20190506_110228.jpg

Scott Guthrie a orchestré le keynote technique portant sur Azure et certains outils de développement. Portant son légendaire polo rouge, il a procédé à plusieurs annonces qui ne sont pas négligeables. Pour les gens qui suivent les nouveautés de manière assidue, rien n’est apparu comme révolutionnaire, mais je pense que c’est du à la cadence de livraison rapide à laquelle Microsoft nous a maintenant habitué. Voyons quand même les éléments dignes de mention.

Annonce de Visual Studio Online

Microsoft fournit maintenant un éditeur web en ligne pour Azure DevOps. Il agira en tant que companion aux éditeurs VS Code et Visual Studio. Des fonctionnalités comme Live Share et IntelliCode sont à prévoir éventuellement.

20190506_112245.jpg

Outillage Azure DevOps

Donovan Brown est revenu sur différents ajouts récents dans l’outillage entourant Azure DevOps comme l’outil Azure CLI qui inclut des extensions pour Azure DevOps. Aussi, l’annonce importante a été celle de pouvoir unifier les pipelines CI/CD dans un seul et même pipeline. Tout ça se fera en YAML. Avec l’ajout récent d’un soutien visuel pour la configuration des tâches, l’expérience devient très intéressante.
Suite à l’acquisition de GitHub, Microsoft continue d’améliorer l’intégration entre GitHub et Azure DevOps en fournissant maintenant des ensembles de licences pour MSDN et GitHub Enterprise ainsi que la possibilité d’utiliser Azure AD pour s’authentifier dans GitHub.

Nouveaux services Azure

Plusieurs services Azure ont été annoncés en aperçu ou en disponibilité générale, mais j’ai noté particulièrement les ajouts à AppService qui disposera d’une intégration VNet pour les applications basées sur Linux. Nos applications .NET Core pourront donc utiliser la même intégration VNet qui est actuellement en aperçu du côté Windows (v2).20190506_113521.jpg

Quelques nouveautés du côté AKS sont aussi digne de mention. Pour commencer, la disponibilité générale des kubelets virtuels. Aussi, il faut voir Kubernetes Event-Driven Auto-scaling (KEDA). Il s’agit de pouvoir gérer l’élasticité des clusters Kubernetes à l’aide des événements disponibles dans Azure et des Azure Functions. Par ailleurs, ces dernières pourront aussi être exécutées sous Kubernetes dans des conteneurs.

20190506_113728.jpg

Plusieurs services de bases de données ont été bonifiés pour offrir des capacités « hyperscale ». Pour les énormes besoins en terme de données ou de performance, les BD opérationnelles pourront utiliser des ressources de grande envergure (Disponible pour SQL Server, MySQL et PostgresSQL).

Power Platform

Microsoft met beaucoup de l’avant les technologies Microsoft 365 dans sa conférence comme les Power Apps, Microsoft Flow et Power BI. Le but de Power Apps est d’offir la possibilité aux organisations de fournir des solutions logicielles sans nécessairement avoir recours à des développeurs. Au minimum, leur tâche sera dramatiquement réduite. Une démo a d’ailleurs été faite démontrant la possibilité de créer une application mobile à partir d’un outil de conception web. Pour en savoir plus, consultez le site PowerApps.

20190506_123049.jpg

.NET Platform Roadmap

20190506_135216

Une session avec les « lower Scotts » avait lieu aujourd’hui au sujet des nouveautés dans le monde .NET. Il faut dire que la grosse nouvelle a été publiée un peu plus tôt dans la journée lorsque .NET 5 a été révélé. Il y aura une seule version de .NET à partir de 2020 pour développer sur toutes les plateformes (Windows, Linux et MacOS). Notons en particulier les possibilités d’interopérabilité avec Java et Swift et les options de compilation JIT et Ahead of Time (AOT). .NET 5 sera la suite de .NET Core. Les applications .NET Framework peuvent donc continuer leur migration vers .NET Core selon les besoins. À noter que la version .NET 4.8 demeurera supportée avec les différentes versions de Windows.

D’autres nouveautés ont aussi été relatées comme ML.NET 1.0 et son Model Builder. Ce dernier permet de créer et entraîner des modèles de machine learning localement sur notre machine. Un assistant facile d’utilisation est rendu disponible directement dans Visual Studio. Les outils .NET pour Apache Spark ont aussi été démontrés de manière complète avec des performances meilleures que Python.

20190506_142125.jpg

Pour ce qui est de .NET Core 3 qui supporte WinForms, WPF et UWP, Microsoft garde le cap et rappel les avantages de migrer nos applications vers .NET Core :

20190506_143501.jpg

Un bref rappel a aussi été fait pour les plus récentes nouveautés de ASP.NET Core 3 comme :

Windows Containers

Pour finir, une session a eu lieu sur l’état des conteneurs dans Windows. C’est définitivement Windows 2019 qui offre le meilleur support pour les conteneurs Windows, mais il m’est apparu assez clair que la maturité n’était pas au rendez-vous. Les tailles d’images demeurent volumineuses et la complexité d’utilisation est plus grande que du côté Linux. Actuellement, il n’est pas possible de récupérer les logs émis par le processus dans le conteneur de manière standard dans StdOut, ce qui limite plusieurs scénarios. À terme, on pourra y retrouver les journaux applicatifs des événements (EventLog) ainsi que certains logs IIS, ce qui est quand même pas mal du tout. Les avancées les plus intéressantes sont du côté de AKS qui permettra d’avoir des noeuds mixtes Windows et Linux.

Conclusion

C’est une première journée très chargée que nous avons eu et nous en attendons une autre semblable demain. Bien qu’il n’y aura pas de keynote à suivre, de multiples présentations très intéressantes tourneront autour d’Azure, .NET et Kubernetes. Stay tuned!

Azure DevOps Wiki + VS Code : Super!

Depuis quelques semaines, je rédige de la documentation pour mon travail autour du DevOps. Nous avons cru bon en équipe d’appliquer ce que l’on prône comme pratique : « Everything as Code ». C’est pourquoi nous avons choisi une approche qui vise à considérer la documentation comme du code. Pour ce faire, nous avons bien entendu opté pour la syntaxe Markdown. Ce « langage » est relativement simple et portable si on utilise les fonctionnalités de base. Pas que je n’ai pas envie de parler de la documentation en tant que code, mais je trouvais intéressant de plutôt partager la démarche qui m’a amené à choisir un ensemble d’outils comme Azure DevOps Wiki et VS Code pour accélérer la mise en place de notre documentation.

Comparaison des plateformes évaluées

L’idée n’est pas d’écrire le résultat complet de l’analyse par laquelle je suis passé, mais je pense que les faits saillants de la comparaison sont intéressants. En effet, différents outils sont disponibles pour rédiger, héberger et publier votre documentation. Certaines plateformes sont Open Source et d’autres sont payantes.

MkDocs

On m’avait déjà parlé de cette plateforme dans le passé. Il s’agit d’une boîte à outils qui permet de générer un site de documentation à partir de fichiers Markdown. Le HTML ainsi obtenu doit alors être publié à l’aide d’un hébergeur ou d’un serveur web quelconque. L’idée n’est pas mauvaise et offre la possibilité de personnaliser l’aspect final et général du site de documentation. Toutefois, il faut être un peu à l’aise en Python ou être prêt à l’apprendre. Comme c’est un des langages les plus populaires dans le monde, ce n’est pas une mauvaise chose! Étant toutefois néophytes dans ce domaine, je n’aimais pas la barrière à l’entrée. Par ailleurs, certaines des équipes avec qui je travaille ont eu des petits problèmes de performance au niveau de la recherche qui peut être longue à s’initialiser. Le moteur de recherche est Lunr.js.

Site MkDocs

DocFx

DocFx est la plateforme de documentation as code de Microsoft. Elle sert à plusieurs de leurs sites de documentation ou est en fait un produit Open Source dérivé de leur vraie plateforme. Son gros avantage est qu’il est plutôt en .NET Core, donc plus facile d’approche que le Python dans mon cas. Cependant, il est aussi basé sur Lunr.js. Comme j’avais peur de vivre les mêmes problèmes de performance que mes collègues, je n’aimais pas l’idée. Le support multilingue prévu pour une nouvelle version prochainement était aussi intéressant.

Pour publier le site en HTML, il faut aussi trouver une manière de l’héberger, ce qui n’est pas intéressant dans l’optique d’un Minimal Valuable Product (MVP). Je voulais valider l’approche « As Code » avant de m’embourber dans les problématiques d’hébergement ou autre.

Site DocFx

Azure DevOps Wiki

C’est alors que j’ai découvert Azure DevOps Wiki. Une plateforme de documentation Wiki fournie avec Azure DevOps. En plus d’être hébergée gratuitement à même notre abonnement Azure DevOps, elle permet de publier les fichiers Markdown directement à partir d’un repo Git.

Publish

On peut choisir la branche de laquelle on veut publier et aussi un sous-répertoire au besoin. Tout changement qui sera inclus dans un commit sera automatiquement en ligne sur le Wiki.

Ce qui est également important dans un site de publication de documentation est d’avoir une bonne navigation. Azure DevOps Wiki permet de structurer la documentation de manière hiérarchique en créant des répertoires dans le repo. C’est plutôt minimal, mais ça « fait la job ». Pour plus de détails sur les options disponibles, consultez la page suivante.

Révisions et collaboration

L’avantage d’utiliser les repos Git pour la documentation vient avec l’utilisation des Pull Request (PR). Auparavant, le meilleur moyen était de distribuer un document à travers un courriel ou par Teams/Slack et de recueillir les commentaires. Il fallait aussi intégrer les commentaires de chacun dans un même document et plusieurs personnes ne pouvaient pas collaborer à la révision en prenant connaissance des commentaires des autres. On aurait peut-être pu utiliser un document en édition partagée, mais cela comporte un certain nombre de défis également.

Avec les PR, on obtient une gestion unifiée des commentaires, la possibilité de désigner des réviseurs qui seront informés par courriel que leur contribution est requise et la possibilité de discuter très tôt de son contenu avec le mode brouillon.

Brouillon

Bref, un excellent outil de collaboration pour de la documentation.

PR

Comment gérer le multilingue ?

Un autre critère de sélection pour notre plateforme était d’être en mesure de gérer les différentes langues d’une manière correcte. Je voulais que la documentation des deux langues puisse faire partie de la même PR afin de comparer le contenu traduit avec l’original et surtout de pouvoir valider que le contenu était fourni dans les deux langues.

Pour ce faire, j’ai opté pour une solution simple : un répertoire racine pour chaque langue. Évidemment, la responsabilité nous incombe de s’assurer que la structure est équivalente dans les deux hiérarchies, mais c’est un compromis acceptable.

Azure DevOps ne supporte pas la gestion des langues lors de la publication. Il faut donc publier deux Wikis distincts : un pour chaque langue. C’est là que prends de l’importance la possibilité de publier un sous-répertoire.

PublishSubfolder

VS Code + Extensions

Pour la création du contenu Markdown, VS Code est un éditeur pas mal du tout si on installe certaines extensions :

  • Markdown All in One :
    Permet plusieurs raccourcis dans l’édition du Markdown comme les effets gras et soulignés, la création de tables des matières et la possibilité d’avoir un panneau de prévisualisation intégré à VS Code.
  • Azure Repos :
    Extension fournie par Microsoft pour gérer les éléments relatifs à Azure DevOps comme les PR.
  • Paste Image :
    Permet de coller une image provenant du presse-papier directement dans le Markdown. Le raccourcir Ctrl + Alt + V crée un fichier dans le même répertoire que le fichier en édition et ajoute un lien où se trouve le curseur.

EditionMD

What’s next ?

Ces outils permettent une mise en place rapide d’un site de documentation. Lorsque des besoins plus spécifiques apparaîtront, on pourrait imaginer de finalement publier le même Markdown avec une des plateformes mentionnées précédemment et, pourquoi pas, intégrer la recherche Bing Search ou QnA Maker d’Azure 😊. Bonne documentation!