Comment Upsun Dispatch gère les processus, de la création d'un ticket au code révisé

Upsun Dispatch est désormais accessible à tous à partir d'aujourd'hui. Notre article précédent explique ce que c'est et pourquoi on l'a créé. Cette fois-ci, on te présente en détail son fonctionnement, les éléments de base qui le composent et les fonctionnalités disponibles dès maintenant. Tu auras aussi un aperçu de notre feuille de route à la fin de l'article.

Les éléments de base

Upsun Dispatch repose sur trois grands éléments de base : le processus, le bac à sable et les intégrations. Le cœur de notre produit, c’est le processus. Voyons ça de plus près.

Un processus est une séquence d’étapes qui te mène d’un déclencheur à un résultat défini. Aujourd’hui, chaque processus comprend un ensemble fixe d’étapes que les agents ou les utilisateurs peuvent exécuter. Notre objectif est de te permettre progressivement de modifier les processus existants, et même d’en créer toi-même à partir de zéro. Pour que le processus fonctionne, tu dois le connecter à une source externe avec laquelle il interagira et définir le type de déclencheur qui lance son exécution.

Voilà un aperçu général de notre primitive principale du processus. Explorons maintenant ses sous-primitives.

Le déclencheur est la condition de démarrage de l’exécution. Les déclencheurs peuvent se déclencher automatiquement lorsqu’un événement est détecté dans un système connecté, comme l’ouverture d’une pull request ou d’une merge request sur GitHub et GitLab, respectivement. Un utilisateur peut lancer une exécution manuellement ; dans la plupart des cas, ça correspond à la mention d’un agent dans l’une des entrées du processus.

Une « exécution » correspond à une exécution d’un processus. Elle comprend des informations telles que : qui l’a lancée, à quelles données l’agent avait accès, les résultats et la durée de chaque étape, qui a pris la décision, ainsi que le résultat final. Tu peux consulter toutes les exécutions au sein de ton organisation Upsun Dispatch. C’est cette exécution que tu ouvres sur la page des exécutions.

Une « étape » correspond à une action du processus. Une étape comporte une condition de démarrage, des entrées et sorties attendues, un délai d’expiration et une politique de réessai. Chaque étape est soit une étape déterministe exécutée par le système, soit une étape gérée par un agent, soit une étape nécessitant une intervention humaine.

Le « contrôle humain » est une étape spécifique qui nécessite une intervention humaine. À la date de lancement, le produit comporte un seul contrôle humain : l’approbation du plan dans le processus « Issue to Code ». Tu peux l’activer ou le désactiver, selon le niveau de confiance que tu accordes aux agents. Dès que le processus atteint un contrôle humain, l’exécution s’arrête jusqu’à ce que l’utilisateur approuve la poursuite de l’exécution.

Maintenant qu’on a exploré la primitive principale et ses sous-primitives, voyons deux autres primitives proposées par Upsun Dispatch.

Le « Sandbox » est un environnement isolé, créé pour une seule étape d’agent et détruit une fois celle-ci terminée. L’agent a accès aux données importées dans le sandbox lors de sa création. Comme le sandbox n’existe que pendant une seule étape, un processus comportant plusieurs étapes d’agent exécute chaque étape dans son propre sandbox.

L’intégration, c’est une connexion entre Upsun Dispatch et un outil que ton équipe utilise déjà.

Les primitives en action : d’un ticket Jira à une pull request validée

Les primitives restent abstraites tant que tu ne les vois pas en action. Prenons donc un exemple concret : un chef de produit demande une modification dans Jira, et quelques minutes plus tard, une pull request validée t’attend sur GitHub.

Comment déclencher l'exécution

Un chef de produit ouvre un tableau Jira et voit un ticket bien décrit. Il s’agit d’une modification importante que les utilisateurs attendent depuis un certain temps. Le chef de produit décide qu’il est temps de s’y mettre. Il ouvre le ticket et ajoute un commentaire : @Upsun Dispatch, implémente.

Ce commentaire sert de déclencheur. Avant que l’exécution ne commence, Upsun Dispatch vérifie deux choses : que le commentaire s’adresse correctement à Upsun Dispatch, et que la personne dispose des droits suffisants pour déclencher Upsun Dispatch sur ce projet Jira. Upsun Dispatch ignore les mentions provenant de personnes sans accès, et aucune exécution ne démarre. Une simple mention sans commande affiche la liste des commandes acceptées par le ticket, et là non plus, rien ne se lance.

Jira est en soi une intégration. Chaque intégration traduit les événements de son outil — un commentaire Jira, une pull request GitHub, une attribution Linear — en un format commun avant qu’ils n’atteignent le processus. C’est pourquoi Issue to Code est un processus unique, avec des sources d’entrée et de sortie : il ne sait pas et ne se soucie pas de l’outil d’où provient la demande.

Dès que le déclencheur est accepté, une exécution apparaît en haut du tableau de bord Upsun Dispatch, visible par tout le monde dans ton organisation. À partir de là, tout ce qui se passe y est associé : qui a demandé, ce que l’agent a vu, ce que chaque étape a produit, combien de temps ça a pris, qui a pris la décision et combien ça a coûté.

Première étape : recueillir le contexte

La première étape est déterministe. Elle récupère le ticket, ses commentaires, les tickets et pull requests associés, ainsi que tous les fichiers mentionnés. Elle vérifie également si le corps du ticket indique à quel dépôt le code doit être ajouté, car les tickets Jira ne disposent pas nativement de cette information.

Elle enregistre ces données pour l’exécution. Celui ou celle qui approuvera le plan plus tard pourra l’ouvrir et voir exactement quelles données l’agent a reçues. C’est la partie que la plupart des outils d’automatisation sautent, et c’est justement celle qui donne tout son sens à l’approbation. Tu n’approuves pas un plan à l’aveugle ; tu approuves un plan en ayant une vision claire du contexte qui l’a généré.

Deuxième étape : le plan

Une fois le contexte rassemblé, on passe à notre première étape d’agent. Un agent de planification lit le paquet de contexte et rédige un plan.

Il s’exécute dans un bac à sable : un environnement isolé créé uniquement pour cette étape, contenant l’ensemble de données contextuelles, et détruit dès que l’étape se termine. L’accès au réseau sortant est bloqué par défaut. Quoi que fasse l’agent, il le fait à l’intérieur de ce bac à sable.

Une fois le plan prêt, une autre étape déterministe le publie sous forme de commentaire sur le ticket Jira, car c’est de là que l’exécution a été déclenchée. Upsun Dispatch l’enregistre également, ce qui te permet de retrouver plus tard tous les détails de l’exécution au même endroit.

Le contrôle humain

Si ton organisation a activé cette fonctionnalité, l’exécution s’arrête alors au contrôle humain. Le processus est mis en pause jusqu’à ce qu’une personne approuve le plan.

La décision est prise sur le ticket Jira, à l’aide de l’une des trois commandes suivantes :

• @Upsun Dispatch plan approve permet de passer à la mise en œuvre de ce que l’agent de planification a suggéré.
• @Upsun Dispatch plan reject <motif> met fin à l’exécution et consigne le motif du rejet.
• @Upsun Dispatch plan revise <commentaire> renvoie l’exécution à l’étape de planification avec ton commentaire joint. Un nouveau plan remplace l’ancien. Chaque itération est enregistrée.

Si personne ne répond dans les sept jours, le « gate » expire et le cycle s’arrête.

C’est à ton organisation de décider si la porte est activée ou désactivée. Les équipes qui font confiance à l’agent de planification pour les petits changements la désactivent. Celles qui veulent qu’une personne soit informée de chaque changement la laissent activée. Dans tous les cas, la décision et son auteur sont consignés dans l’exécution.

Étape 3 : le code

Notre chef de produit donne son accord. L’agent de codage démarre dans un nouvel environnement de test, avec le dépôt cloné et le plan approuvé comme données d’entrée. Il y a deux choses à savoir sur cet environnement de test.

Le jeton du dépôt utilisé par l’agent est en lecture seule et limité à ce dépôt précis. Il est injecté au niveau de la couche réseau, donc l’agent ne le détient jamais. Et l’agent ne peut pas pousser une branche ni ouvrir une pull request depuis l’intérieur du bac à sable. C’est une étape ultérieure et déterministe qui s’en charge. L’agent écrit la modification en tant que résultat de l’étape.

Étape 4 : la critique

Avant que quoi que ce soit n’atteigne GitHub, un troisième agent, le critique, lit le diff généré par l’agent de codage. Il s’exécute dans son propre bac à sable, comme une étape à part entière, et il ne voit que le diff, pas l’intégralité du dépôt. Considère-le comme le premier relecteur, celui qui lit la modification avant tout le monde.

Il pose deux types de questions. La modification a-t-elle répondu à la demande ? Le critique compare le diff au plan approuvé et signale tout objectif qui a été ignoré, réalisé à moitié ou discrètement restreint. Et ce qui a été développé est-il solide ? Bugs logiques, gestion des erreurs manquante, risques liés aux secrets ou à l’injection dans le nouveau code, plantages avec une entrée vide, signature modifiée qui va casser ses appelants. Les détails de style sont volontairement exclus du champ d’application. Une liste vide de remarques signifie que la modification semblait solide.

Les résultats sont intégrés à la description de la pull request, de sorte que le relecteur humain ouvre la pull request avec les notes du critique déjà présentes. Cependant, si le critique détecte une modification qui ne compile même pas, une erreur de syntaxe dans une ligne ajoutée par exemple, il empêche l'ouverture de la pull request. L'exécution s'arrête et explique pourquoi dans le ticket Jira, et c'est à toi de décider si tu veux réessayer.

Étape 5 : la pull request

Une étape déterministe pousse la branche et ouvre la pull request sur GitHub. L’auteur du commit est la personne qui a demandé la mise en œuvre. Dispatch est le committer et un co-auteur. L’historique Git montre qui a demandé ça et qui a fait le travail. Un commentaire est ajouté à la ticket Jira avec le lien.

Le nom de la branche est fixe pour chaque ticket ; ainsi, une deuxième exécution sur le même ticket pousse vers la même pull request au lieu d’en ouvrir une autre qui ferait double emploi.

Une dernière étape vérifie qu’une pull request a bien été ouverte. Si ce n’est pas le cas, l’exécution est signalée comme ayant échoué, et non comme terminée.

Étape n° 6 : la révision

Le push déclenche un autre processus. La révision du code commence sur la nouvelle pull request, comme c’est le cas pour toutes les pull requests de ce dépôt, y compris celles ouvertes par Dispatch. Le système lit le diff et le ticket associé, vérifie l’intégration continue (CI), puis publie une révision sur GitHub. Il ne fusionne jamais. C’est ta protection de branche qui décide ce qui passe en production, comme avant.

Ce dont tu disposes le jour du lancement

Maintenant qu’on a passé en revue tous les éléments de base, voyons ce qui est disponible dans Upsun Dispatch à ce jour.

Tu commences avec trois processus.

La révision de code s’exécute sur les pull requests de GitHub et les merge requests de GitLab. Elle compare le diff à l’issue associée, signale les problèmes d’architecture et les changements de compatibilité, puis publie un commentaire dans l’outil. Elle s’exécute automatiquement à chaque modification, ou sur demande avec @upsun-dispatch review.

« Issue to Code » est le processus qu’on vient de suivre. Il part d’une mention dans un ticket GitHub, d’une mention dans un ticket Jira ou d’une attribution dans Linear, et ouvre la modification sur GitHub ou, depuis Linear, sur GitLab. L’approbation des plans correspond au paramètre d’organisation décrit plus haut.

L’analyse CVE vérifie les dépendances d’un dépôt par rapport aux vulnérabilités connues et signale ce qu’elle détecte.

En plus des processus, tu disposes aussi d’intégrations avec GitHub, GitLab, Jira et Linear. Les réviseurs et les validateurs interviennent depuis l’outil qu’ils utilisent déjà ; un accès en écriture suffit. Tous les membres de l’organisation voient chaque exécution. Le temps d’agent et les jetons sont affichés par exécution, et la page « Utilisation » les regroupe par processus et par dépôt. Tu fournis ta propre clé de modèle, Anthropic ou OpenAI, et les jetons restent sur la facture de ton fournisseur. Le temps d’agent est payé à partir d’un portefeuille prépayé, sans prix par utilisateur ni limite de dépôts. Et il y a une formule gratuite : 20 minutes d’agent par jour, sans carte bancaire.

Un aperçu de la feuille de route

On a d’abord mis en place les fonctionnalités de base avant de développer les fonctionnalités avancées, et les prochains mois seront consacrés à leur déploiement.

Aujourd’hui, les processus sont fixes. Tu peux activer ou désactiver une porte, définir le déclencheur sur automatique ou manuel, et configurer des options par référentiel, mais tu ne peux pas ajouter d’étape ni en créer toi-même. Les processus modifiables, utilisant le même vocabulaire d’étapes et de portes que tu viens de découvrir, seront notre prochaine fonctionnalité.

Aujourd’hui, chaque exécution collecte son contexte à chaque fois. La conservation des informations de projet, visibles et modifiables par ton équipe, viendra ensuite.

Aujourd’hui, la révision est consultative et ne corrige pas ce qu’elle détecte. Un processus de correction automatique est en préparation ; il ouvrira une modification à approuver par une personne, et non à fusionner.

Aujourd’hui, les déclencheurs sont des événements dans les outils connectés, ainsi que des exécutions manuelles. Les exécutions planifiées seront bientôt disponibles.

La seule fonctionnalité qu’une entreprise de plateforme peut apporter, c’est la vérification : mettre en place un environnement réel pour une modification, l’exécuter là-bas, puis le démanteler. C’est cette capacité que nous nous efforçons de développer, en tirant parti de notre héritage Upsun Cloud.

Essaie-le sur un ticket que tu as déjà

Ne commence pas par la pull request ; commence par le ticket. Demande à Upsun Dispatch de mettre en œuvre la modification, puis rends-toi dans « Runs ». Ouvre le bundle de contexte et vérifie si l’agent disposait de ce dont un collègue aurait eu besoin. Lis le plan avant de consulter le diff. Lis ensuite la revue qu’Upsun Dispatch a publiée sur sa propre pull request. Si cette chaîne est cohérente, c’est que le produit fait son travail. S’il manque un maillon dans la chaîne, dis-le-nous, car la chaîne, c’est le produit.

Prêt à commencer ? Inscris-toi, connecte un dépôt, ajoute ta clé de modèle, et mentionne Upsun Dispatch dans un ticket que tu as déjà créé.