Cloudflare a lancé le service Worker Previews afin de fournir un environnement d’exécution indépendant pour chaque branche Git, permettant de tester les modifications du code dans des conditions plus proches de la production sans affecter le trafic, les paramètres ou l’état propre de la version en fonctionnement. Le service est désormais disponible pour les utilisateurs de Workers.
Chaque aperçu dispose d’une URL stable pour la branche, mise à jour à chaque nouvelle opération de push, ainsi que de paramètres, variables, secrets et liaisons séparés. Les développeurs peuvent envoyer des requêtes vers l’aperçu depuis le terminal, les systèmes d’intégration continue ou le navigateur, puis examiner les journaux, les erreurs, les métriques et les traces d’exécution grâce aux outils Workers Observability.
Un environnement indépendant qui va au-delà d’un simple lien vers la version
Cloudflare explique que Worker Previews diffère des précédentes Version URLs. Ces dernières renvoient vers une version téléversée précise et peuvent utiliser des ressources de production, tandis que Worker Previews crée un environnement isolé pour chaque branche, avec la possibilité d’exécuter des centaines d’aperçus en parallèle dans un même tableau de bord. Cela permet de tester les points de terminaison API, les modifications de l’interface utilisateur et les parcours de connexion dans un contexte d’exécution réel, plutôt que de se contenter d’examiner le code ou de dépendre d’un environnement staging partagé.
Lors de l’exécution de la commande npx wrangler preview, Cloudflare crée la version d’aperçu à partir d’une configuration de base définie par le développeur dans le fichier Wrangler. Il est possible de modifier les paramètres d’un aperçu donné, par exemple pour le diriger vers une base de données ou une clé API de test, sans changer les paramètres de production ni ceux des autres aperçus. Les adresses des aperçus peuvent également être fournies via un domaine personnalisé, avec l’utilisation de Cloudflare Access pour les protéger et en limiter l’accès.
Isolation de l’état et des ressources sensibles
L’isolation s’étend aux ressources avec état. Chaque aperçu dispose d’un espace Durable Objects et d’applications Containers indépendants, ce qui empêche les modifications d’état, les sessions, les opérations de migration ou les changements de schéma défaillants d’atteindre la production ou d’autres branches. Cloudflare relie ce comportement au contexte logiciel de la branche : ctx.exports se résout vers l’espace de production lors de l’exécution en production, et vers l’espace d’aperçu approprié lors de l’exécution au sein d’une branche expérimentale.
En pratique, cela permet de comparer différents paramètres pour une même application, par exemple en testant les performances d’une exécution à froid et à chaud, tout en conservant les résultats de chaque expérience dans son environnement. Il est également possible d’utiliser Browser Run pour ouvrir l’URL de l’aperçu dans un navigateur sans interface, exécuter des parcours de connexion et capturer des instantanés ou des sessions rejouables, puis relier ce qui est apparu à l’utilisateur aux traces d’exécution et aux erreurs enregistrées.
Qu’est-ce qui change concrètement ?
Worker Previews fournit une boucle de rétroaction avant la production pour chaque branche : déployer la modification, l’exécuter, la surveiller, corriger le problème, puis la tester à nouveau avant la fusion. Cloudflare estime que cela soutient ce qu’elle appelle le cycle de vie du développement des agents, dans lequel l’agent logiciel peut effectuer la modification, l’examiner et vérifier ses résultats dans le périmètre de la branche elle-même, avec la possibilité pour un réviseur humain d’intervenir si nécessaire.
Cloudflare a utilisé le service en interne pour tester CloudflareOS et Gatekeepers, notamment les parcours combinant OAuth, les autorisations, les approbations et l’état de l’application. L’entreprise a également cité des expériences de Supermemory et de Ramp concernant le test de modifications de Workers et la révision de demandes de fusion depuis des appareils mobiles.
Limitations annoncées et prochaines étapes
Les aperçus n’isolent pas encore l’intégralité de la chaîne de requêtes dans les applications composées de plusieurs Workers ; une liaison de service depuis un aperçu peut ainsi appeler la version de production du Worker associé. Les aperçus peuvent également envoyer des messages vers Queues, mais ne les consomment pas encore, et l’isolation de l’exécution de Workflows nécessite une configuration séparée. Cloudflare travaille à la prise en charge de ces parcours, ainsi qu’à la fourniture d’aperçus de longue durée pour les environnements staging, QA et les environnements de développement continus.
Lecture de certi.news : la valeur essentielle de cette annonce ne réside pas dans la création d’un nouveau lien de test, mais dans le déplacement de l’isolation au niveau des paramètres, de l’état et de la surveillance. Cela réduit les risques liés au test de modifications touchant des ressources avec état, mais ne supprime pas la nécessité de concevoir soigneusement l’environnement de test, notamment lorsque le service dépend de plusieurs Workers, de files d’attente, de messages et de flux de longue durée. Worker Previews semble donc plus complet que l’aperçu d’une version individuelle, même si certaines parties de l’application restent en dehors du modèle d’isolation complet dans la version actuelle.