InfoQ FR a souhaité en savoir plus sur Vorlon.JS, le debugger open Source à distance de Microsoft. Echanges avec Julien Corioland, évangéliste technique chez Microsoft France, autour du processus de développement de ce nouvel outil.
InfoQ FR : Bonjour Julien, peux-tu te présenter en quelques mots pour nos lecteurs ?
Julien : Je suis évangéliste technique chez Microsoft France, avec un focus particulier sur la plateforme applicative Cloud, Microsoft Azure, ainsi que sur les scénarios DevOps qui l’accompagnent. Je m’intéresse également aux architectures micro-services et aux différentes solutions technologiques qui permettent de les mettre en place. J’ai rejoint l’équipe Vorlon.JS pour travailler à la mise en place de certaines pratiques « DevOps », comme l’intégration continue ou le déploiement continu.
Vous pouvez me contacter via Twitter : @jcorioland
InfoQ FR : Peux-tu nous redonner rapidement le contexte autour de Vorlon.JS et sur l'usage de cet outil ?
Julien : Vorlon.JS a été créé à l’origine pour résoudre les problèmes liés au débug de sites web sur plateformes mobiles. Plutôt que de devoir utiliser un outil spécifique à chaque plateforme/navigateur (Chrome/Safari/Edge…), Vorlon.JS propose au développeur une seule et unique interface pour reproduire une expérience proche des traditionnels « F12 » (DOM explorer, Network Explorer, Console…).
Au-delà de l’aspect purement « debug », Vorlon.JS permet aussi d’améliorer le code et la qualité d’une application au travers de ses différents plugins, une dizaine aujourd’hui, dont certains développés par la communauté Open Source. Plus récemment, l’équipe a également travaillé sur le support du débug de processus Node.JS.
InfoQ FR : De quelle façon avez-vous intégré un process DevOps et CI pour un produit comme Vorlon.JS, construit avec gulp ?
Julien : La première discussion autour du sujet s’est passée pendant un hackathon DevOps. A la base, on cherchait un prétexte pour participer, et à la fin, on s’est rendu compte qu’un certain nombre de pratiques DevOps qu’on avait mises en place pouvaient nous faciliter la vie sur le projet.
Tout le travail autour de la récupération des packages npm ou la transformation des fichiers TypeScript en JS, l’exécution des tests unitaires avec Gulp, etc. était déjà fait, puisque c’est comme ça que Vorlon.JS a toujours été packagé depuis son repo GitHub.
Ce qu’on a fait, c’est simplement automatiser toutes ces tâches au sein d’un processus d’intégration continue pour faire en sorte que ce soit fait à chaque commit.
Pour cela, il nous fallait un outil. Nous avons choisi Visual Studio Team Services (VSTS), une offre SaaS proposée par Microsoft centrée sur le travail en équipe et l’industrialisation des projets de développement. C’est une évolution de Team Foundation Server pour le Cloud.
Son système de build automatisé propose nativement des tâches qui permettent d’exécuter du Gulp, NPM, Grunt, Maven… (et bien d’autres !). C’est donc assez simple de s’intégrer dans l’outil quelle que soit la technologie utilisée.
Par exemple, pour les tests unitaires, on a choisi MochaJS, et on utilise un reporter qui génère un fichier au format JUnit qui nous permet d’intégrer les résultats des tests directement dans le dashboard VSTS :
InfoQ FR : Utilisez-vous Vorlon.JS pour tester Vorlon.JS ? De manière automatisée/automatisable ?
Julien : Non, pour une raison simple, c’est qu’il faudrait tester le dashboard de Vorlon.JS mais que celui-ci n’est pas destiné à être exécuté sur mobile.
Ce à quoi nous réfléchissons actuellement est d'automatiser des tests d’interface graphique sur le dashboard à l’aide d’un outil comme Selenium par exemple. Là encore, c’est un process qui est relativement simple à mettre en place en utilisant Visual Studio Team Services. Pas besoin de changer d’outil !
InfoQ FR : Est-ce que tu peux situer un peu les avantages/inconvénients d'une solution de ce type, par rapport à TravisCI, CircleCI ou Jenkins qui sont souvent employés en CI de projets JS ?
Julien : On a choisi VSTS car il ne s’agit pas que de CI. On peut également l’utiliser pour gérer du déploiement en continu (Release Management) avec des workflows de validation plus ou moins complexes, déclencher des tests de charge automatisés ou gérer des campagnes de tests fonctionnels par exemple. En plus de ça, le fait qu’il soit capable de s’intégrer avec des outils de gestion de code source tiers comme GitHub ne gâche rien à la fête.
Au final, nous bénéficions de toutes les fonctionnalités que nous souhaitions utiliser dans VSTS, sans avoir à changer nos habitudes de développement, puisque le code est toujours sur GitHub et que nous gérons toujours la roadmap et les bugs avec les issues GitHub.
InfoQ FR : Utilisez-vous des instances de serveurs jetables, ou des instances plus long-terme ?
Julien : En fait, on utilise les deux. On utilise VSTS pour faire du Release Management, ce qui nous permet de déployer en quelques clics une nouvelle version de Vorlon.JS sur plusieurs environnements que nous utilisons principalement pour les démonstrations.
D’ailleurs, on ne parle pas uniquement de serveurs, mais plutôt d’environnements que l’on a choisi de gérer dans Microsoft Azure. On décrit nos environnements en JSON pour qu’ils puissent être déployés par Azure Resource Manager, et on automatise ces déploiements avec VSTS. Un autre avantage est qu’on peut aussi automatiser le déprovisionnement d’un environnement si on ne veut plus l’utiliser et donc, arrêter de le payer. Le concept de « disposable infrastructure » est vraiment central dans la manière dont nous avons implémenté les workflows de déploiement.
InfoQ FR : Quels sont approximativement les coûts pour ce type de solution ?
Julien : Visual Studio Team Services est gratuit pour les petites équipes. Microsoft fournit un agent de build hébergé, utilisable gratuitement pendant un certain temps de build par mois. Pour des besoins avancés, il est possible de créer son propre agent (sur une VM ou un simple laptop de dev) Windows, Linux ou Mac OS.
Ensuite, tout dépend de l’infrastructure que l’on va déployer en utilisant ces outils. Les serveurs, même de tests ont un coût, mais comme on le disait précédemment, ils sont jetables, ce qui permet de réduire pas mal les dépenses. L’automatisation permet aussi d’éviter d’oublier des serveurs qui seraient facturés pour rien.
InfoQ FR : Comment composez-vous dans votre processus de développement, les outils Microsoft et les outils open source de la boite à outils habituelle d'un développeur (node.js/npm, gulp, GitHub, Docker…) ?
Julien : Comme on le disait, Vorlon.JS est développé en Node.JS. Pour ça, on utilise Visual Studio Code. C’est un outil gratuit, open source et cross-plateformes destiné aux développeurs fullstack web. On peut le comparer à un SublimeText avec en plus, une intégration native à Git et la possibilité de débugger du NodeJS en pas à pas.
Bien sûr, le code source est dans GitHub et on utilise NPM, Gulp qui s’intègrent parfaitement dans Visual Studio Code. Concernant Docker, on vient de publier une image sur le Docker Hub qui permet de créer une instance de Vorlon.JS en quelques secondes. Et là aussi, on a utilisé un build dans VSTS pour automatiser tout le process, de la création de l’image jusqu’à son envoi dans le hub.
InfoQ FR : Comment testez-vous les différentes briques qui composent Vorlon.JS (core, plugins, tests unitaires, intégrations, e2e ...) ?
Julien : Honnêtement, les tests constituent un chantier en cours sur Vorlon.JS. Pour l’instant, on s’est surtout concentrés sur des tests manuels. Le fait d’avoir aujourd’hui un process de CI en place apporte un contexte plutôt favorable à poursuivre l’écriture de tests unitaires.
Et comme on le disait plus tôt, la mise en place de tests UI avec Selenium fait aussi parti de nos plans.
InfoQ FR : Fonctionnez-vous déjà en déploiement continu dans les répos npm ?
Julien : On le fait déjà pour publier les nouvelles versions des images Docker, et npm est dans les starting blocks. Petite anecdote qui prouve le bénéfice d’automatiser ce type de process : vous avez peut-être remarqué qu’on est passé de la version 0.1 à 0.2.1 dans npm, tout simplement parce que la 0.2 était un fail et qu’on ne peut pas supprimer une version dans npm. En automatisant, on n’aurait certainement pas eu ce problème.
InfoQ FR : Où en êtes-vous dans votre démarche DevOps ? Quelles sont les prochaines étapes ?
Julien : Déjà, les premiers bilans sont très positifs. On a réussi à simplifier énormément de choses et surtout à être plus sereins à chaque fois qu’une modification est faite. Par nous ou par la communauté ! Clairement, ça nous fait gagner en temps et en efficacité.
C’est difficile de dire où on en est précisément, car en DevOps, il s'agit plutôt de se mettre dans une démarche d’amélioration continue. Il est important de se remettre en question continuellement, d’autant qu’on a énormément de nouvelles idées pour Vorlon.JS. Et donc forcément, ça aura des impacts sur les différents processus qu’on a mis en place. Tout ce qui compte pour nous, c’est qu’on soit meilleurs qu’hier et certainement moins bons que demain !
InfoQ FR : Merci Julien pour toutes ces réponses !