DEVOXX France

Kevin DAVIN

Jean-Philippe BACONNAIS

Logan WEBER

Matthieu VINCENT

Ce BOF est prévu pour être une session interactive avec des utilisateurs(trices) de GitLab (mais ceux et celles qui n'utilisent pas sont les bienvenues aussi 🧡) pour discuter des fonctionnalités marquantes en 2022 et début 2023.

Mais pas marquantes d'un point de vue vendeur ou product manager, marquantes d'un point de vue personnel (les choses que l'on adore, les choses que l'on déteste, les choses que l'on aimerait avoir, ...).

L'intérêt de ce BOF est aussi pour chacun de découvrir des fonctionnalités qu'il ne connaissait pas et d'échanger avec d'autres personnes et des fans (mon petit doigt me dit qu'il y aura plusieurs GitLab Heroes pas loin).

Laurent DOGUIN

Romaric PHILOGÈNE

Si on passe du temps à créer des scénarios de tests end-to-end de qualité, ce n'est pas juste pour les lancer sur notre machine de dev, à la recherche d'une régression. C'est aussi pour réaliser ses tests dans des conditions proches si ce n'est identiques aux conditions de production.

Mais pourquoi diable se lancer là-dedans ? Quels genres de problèmes qu’on ne trouve pas en dev peut-on identifier ?

Qui plus est, c’est une tâche fastidieuse : il faut recréer un environnement iso prod, importer les données nécessaires aux scénarios de tests, vérifier que tout est correctement déployé, lancer les tests, récupérer et analyser les résultats, les comparer aux précédents runs, et finalement supprimer ces environnements quand ils ne sont plus nécessaires.

Dans ce hands-on lab nous vous faisons découvrir une architecture de déploiement flexible et automatisable reposant sur Qovery pour les applications, Couchbase Capella pour les bases de données et Gitlab pour les pipelines de test et de création d'environnements.

Les promesses de WebAssembly (WASM) pour exécuter du code dans le navigateur à partir d'un binaire (codé en Rust, Go, C, ...) sont remplies. Ses qualités (rapidité, efficacité, sécurité, polyglotte) destinaient de fait WebAssembly à pouvoir être exécuté sur une large variété de plateformes (autre que la VM JavaScript) pour de nombreux cas d'utilisation, tels:

• des plugins pour des applications (par ex Zellij)
• des filtres pour des proxies (par ex Envoy)
• des user defined functions pour des BDD (par ex ScyllaDB)
• des fonctions pour des FaaS (par ex Fermyon Platform) Tout ceci est possible grâce à la spécification WASI (WebAssembly System Interface) qui permet à du code WASM d'être exécuté dans contextes variés.

L'exécution de modules WASM par une application Java était encore il y a peu quasi impossible ou "acrobatique", et ce, même si GraalVM propose un support de WASM (trop léger et peu ou pas documenté).

Cette lacune est aujourd'hui comblée grâce au projet Extism qui permet d'écrire des plugins WASM en différents langages pour vos applications Java.

Lors de ce TIA, je vous expliquerais comment développer une application Vert-x avec des plugins WASM en Rust, Go et Zig.

Pierre-Antoine GRÉGOIRE

Vous avez besoin d'intégrer une chaîne de build, simple ou très élaborée, et de la connecter à une chaîne de déploiement efficace et contrôlée ?

Vous voulez pouvoir observer et analyser l'exécution, la performance, la sécurité de ces flux vitaux pour la dynamique de votre système?

Venez découvrir avec nous comment permettre à la plomberie de votre système de rester saine, performante et adaptable.

Nous allons présenter des concepts et patterns, ainsi que les solutions disponibles pour implémenter l'intégration, l'inspection et le déploiement continus.