Les plates-formes d'exécution commencent à rivaliser pour accéder à la chaîne d'outils full-stack

Dès qu’un projet commence à toucher simultanément SSR, tâches en arrière-plan, stockage d’objets et déploiement en avant-première, l’outil de construction révélera bientôt ses limites d’origine. vite dev est responsable de l’exécution de la page, du renvoi de la gestion du framework de test, du déploiement de la CLI pour la mise en ligne et de l’ajout d’une couche de colle à la couche d’adaptation d’exécution. Au début, cet ensemble de choses était tolérable, mais une fois que le projet a séparé le débogage local et l’exécution en production, des problèmes ont commencé à surgir : il pouvait s’exécuter localement, mais la préversion échouait ; lorsque la version de l’adaptateur a été mise à niveau, les liaisons de file d’attente et de stockage n’étaient plus compatibles ; les commandes étaient toujours les mêmes et je savais déjà que chaque couche pouvait avoir des problèmes indépendamment.

Le changement le plus évident dans la chaîne d’outils depuis deux ans est que la plateforme ne se contente plus de la « dernière étape de déploiement ». Ils ont commencé à aller de l’avant, en réunissant le développement local, la simulation d’exécution, les retours de tests et les commandes de publication dans le même lien. Avec la récente fusion de VoidZero dans Cloudflare, ce qui mérite vraiment d’être surveillé, ce n’est pas l’actualité de l’acquisition elle-même, mais un signal plus clair : les plates-formes d’exécution commencent à rivaliser directement pour l’entrée dans la chaîne d’outils full-stack.

Une fois que l’outil de construction atteint le runtime, la limite de la plate-forme avance

Au sens traditionnel, les responsabilités d’un outil de build sont très claires : lire le code source, générer le bundle et le transmettre au système suivant pour traitement. Cette division du travail n’est plus suffisante. Tant que l’application dispose de fonctions de routage côté serveur, de bases de données, de files d’attente, de stockage d’objets et de périphérie, l’achèvement de la construction ne signifie pas l’achèvement de la livraison. Il reste encore toute une section de sémantique d’exécution à aligner.

Le point le plus facile pour ce type de projet de rester bloqué n’est pas de savoir si le bundler est suffisamment rapide, mais si ce qui s’exécute localement cette fois est le même runtime défini en ligne. Tant que la réponse est non, la boucle de développement deviendra de plus en plus lourde. Afin de combler cette lacune, la plate-forme trouvera certainement un moyen d’intégrer le serveur de développement dans son propre environnement d’exécution et de faire de « l’écriture de code localement » et de « l’exécuter en ligne » le même modèle.

Ainsi, les changements que nous constatons maintenant ne concernent plus seulement le fait que la plate-forme fournit un adaptateur pour un certain cadre, mais à leur tour, la propre CLI, les plug-ins d’exécution et l’environnement local de la plate-forme sont transformés de manière proactive en une forme de chaîne d’outils que les développeurs connaissent déjà. De cette façon, l’entrée change. La plateforme n’attend plus l’apparition de l’étape deploy. Il est déjà entré sur le marché à partir de dev, build, test et même du format d’invite d’erreur.

Agent a amplifié toutes les petites frictions dans la chaîne d’outils qui pouvaient être tolérées.

Lorsque ce sujet est placé au stade de développement purement manuel, le rythme n’est pas si urgent. Les gens se souviendront quelles commandes doivent être exécutées plus d’une fois, quelles erreurs ne sont que des problèmes environnementaux et quels adaptateurs tremblent occasionnellement. Une fois l’agent arrivé, ces ambiguïtés se transforment essentiellement en coûts.

L’agent extraira à plusieurs reprises le serveur de développement, réexécutera le test, lira les erreurs, modifiera le code et vérifiera à nouveau. Commandes incohérentes, journaux irréguliers et comportement d’exécution incohérent. Ces petits bugs préalablement résolus par l’expérience deviendront directement une boucle infinie dans la boucle d’exécution. Bien sûr, la vitesse de construction, la vitesse de test et la vitesse de peluches sont également importantes, mais ce qui est plus précieux est de savoir si l’ensemble du lien a des contraintes unifiées : le même ensemble de CLI, le même ensemble de modèles de configuration, le même type de sortie d’erreur et la même relation de mappage local et de production.

C’est pourquoi le statut des outils comme Vite évolue. À l’origine, ils n’étaient que l’équipement le plus utile dans la couche de construction frontale, mais ils sont maintenant progressivement devenus la base par défaut d’Agent qui est la plus facile à conduire de manière stable. Rapide, simple et largement compatible. Ces avantages servaient autrefois principalement à l’expérience de développement, mais désormais ils servent directement la fiabilité d’exécution. Tant que la plateforme attache ses capacités d’exécution à cette boucle par défaut, elle obtiendra non seulement une cible de déploiement, mais aussi tout un ensemble d’habitudes de génération et de vérification d’applications.

Ce qui est vraiment précieux, ce n’est pas l’alignement du framework, mais la suppression du workflow par défaut.

Rien qu’en regardant les gros titres de l’actualité, il est facile d’interpréter de telles actions comme un investissement écologique ou comme une plateforme souhaitant détourner le trafic vers ses propres services d’hébergement. Les changements les plus sensibles en matière d’ingénierie se situent en réalité à un autre niveau : une fois que l’échafaudage de projet par défaut, le moteur d’exécution local par défaut, la boucle de test par défaut et les commandes de publication par défaut tomberont tous sur la même chaîne d’outils, l’unité de concurrence des plates-formes passera de “dont la machine est la moins chère” à “qui définit en premier comment l’application est créée”.

Cette différence n’est pas minime. Les prix peuvent être comparés horizontalement. Une fois le workflow inscrit dans l’entrepôt, les scripts, le CI et les habitudes de l’équipe, il est rarement facile à modifier. Si la plateforme ne peut prendre en charge que la dernière étape du déploiement, le seuil de migration n’est pas élevé ; si la plateforme a repris l’intégralité du chemin de dev à deploy, la migration affectera l’environnement local, les habitudes de commande, les liens de prévisualisation, les méthodes de débogage et les scripts d’exécution de l’agent. C’est souvent cette couche qui forme réellement le caractère collant.

Cette récente vague de mouvements fait également ressortir autre chose : la chaîne d’outils full-stack redéfinit le « neutre ». Dans le passé, la neutralité signifiait davantage qu’il était indépendant du framework et fonctionnait sur différents bundles. Aujourd’hui, les exigences de neutralité sont plus strictes. Les capacités de la plateforme doivent être connectées, mais la chaîne d’outils elle-même ne peut pas être transformée en un protocole privé de la plateforme. Celui qui peut conserver la couche d’abstraction indépendante du fournisseur tout en faisant de sa propre implémentation l’expérience par défaut aura plus de chances d’obtenir la prochaine série de bonus d’entrée.

Ce parcours ne convient qu’aux équipes qui ont été freinées par la complexité de la livraison

Tous les projets n’ont pas besoin de se soucier de ce type de conflit d’entrée. Pour les sites statiques, les petits backends ou les services avec un seul formulaire de déploiement, il peut être judicieux de continuer à séparer la construction, les tests et le déploiement. Lorsque l’échelle du projet est de grande envergure, ces types de problèmes surgiront rapidement :

• Les différences entre le développement local et l’exécution en ligne ont commencé à prendre du temps de dépannage à plusieurs reprises.
• SSR, file d’attente de tâches, stockage d’objets et liaison de base de données apparaissent tous dans le même entrepôt
• Les équipes s’appuient déjà sur des environnements de prévisualisation, des commandes d’échafaudage et des modèles CI pour une livraison collaborative
• Les agents participent au codage, à la correction des bogues et aux tests, et la stabilité de la chaîne d’outils commence à affecter directement le résultat.

À ce stade, il est un peu tard pour traiter l’outil de construction comme un pur composant de couche frontale. Il fait déjà partie du point d’entrée de l’application, connecté au runtime, au déploiement et à l’exécution. La fusion de VoidZero et Cloudflare ne fait que rendre cette question plus claire : le prochain cycle de concurrence entre plateformes ressemblera de plus en plus à une compétition pour le flux de travail par défaut. Celui qui bouclera cette chaîne le plus facilement aura plus de chances de décider en premier sur quelle base l’application se développera.