Exécutions, portes et processus : les éléments de base, expliqués

La plupart du temps, quand les gens demandent « comment ça marche vraiment ? », ça se résume à trois mots utilisés avec précision : processus, exécution et point de contrôle. Voilà ce que chacun d’entre eux signifie, et comment ils s’articulent entre eux.

Le processus, c’est la définition, pas l’exécution

Point clé : un processus, c’est le modèle. Il ne fait rien tout seul, il définit ce qui se passe quand quelque chose le déclenche.

Dans Upsun Dispatch™, un processus est une séquence définie d’étapes, dont certaines sont effectuées par un agent, d’autres nécessitant une décision humaine. Il est rédigé une seule fois et s’applique à tous les événements futurs correspondant à son déclencheur. À son lancement, Upsun Dispatch intègre « PR Review » comme processus par défaut : un agent lit une pull request et publie une revue structurée avant qu’un humain ne la voie ; sans étape intermédiaire, la revue elle-même constitue le résultat final.

La définition d’un processus comprend ce qui le déclenche (un événement comme l’ouverture d’une pull request, une mention dans un ticket ou un calendrier), les étapes qu’un agent effectue, et à quel moment, le cas échéant, le processus nécessite une décision humaine avant de continuer. Modifier la définition du processus change le comportement de toutes les exécutions futures. Ça n’affecte pas les exécutions déjà terminées.

Une exécution est une instance spécifique du workflow

Point clé : une exécution est une instance unique d’un processus agissant sur une tâche spécifique. C’est ce qui est consigné, et ce que tu regardes réellement quand tu vérifies l’avancement.

Si un processus est la recette, une exécution est une instance spécifique de sa mise en œuvre. Une pull request est ouverte, le processus de révision des PR se déclenche, et cette instance spécifique — cette PR, ce diff, cet horodatage — constitue une exécution.

Chaque exécution dispose de son propre historique : ce qui l’a déclenchée, le contexte utilisé par l’agent, ce qu’elle a produit et ce qu’elle a coûté. Cet historique est stocké sous forme de données immuables, liées de manière permanente à l’exécution, et non à la définition du processus. Deux exécutions d’un même processus peuvent avoir des résultats totalement différents : l’une peut se terminer sans problème, sans intervention humaine, tandis qu’une autre peut se heurter à un obstacle et rester en attente.

C’est à ce niveau que le coût est suivi, par exécution, attribué à l’exécution spécifique qui l’a consommé, et non regroupé en un seul chiffre pour l’ensemble du processus ou de l’équipe.

Un « gate » est un arrêt défini, pas une notification

Point clé : un « gate » est un point du processus où l’exécution s’interrompt et attend une décision humaine explicite. Rien ne franchit un « gate » tout seul.

Une barrière est un point choisi délibérément par le concepteur du processus, pas quelque chose qui se produit par défaut. Quand une exécution atteint une barrière, elle s’arrête. Elle ne continue pas tant qu’une personne ne l’a pas approuvée, rejetée ou renvoyée avec des commentaires. Cette décision, ainsi que le nom de la personne qui l’a prise, est intégrée au dossier permanent de l’exécution.

Les « gates » sont acheminées vers la personne chargée de prendre la décision. Une « gate » relevant de l’ingénierie est transmise à un ingénieur. Une « gate » qui concerne le comportement face à l’utilisateur peut être acheminée vers l’équipe produit. Celle qui concerne les accès ou les données peut être acheminée vers la sécurité. C’est le processus qui détermine quelles « gates » existent et vers qui elles sont acheminées, et non un paramètre par défaut fixe qui traite toutes les décisions de la même manière.

Tous les processus n’ont pas besoin d’un point de contrôle. La révision des PR, telle qu’elle fonctionne aujourd’hui, n’en a pas : la révision structurée qu’elle produit est le livrable, et une personne la lit comme elle lirait n’importe quel autre commentaire sur la pull request. Un processus qui écrit du code et ouvre une pull request comporte généralement au moins un point de contrôle avant toute fusion.

Comment ces trois éléments s’articulent

Point clé : un processus peut générer de nombreuses exécutions. Chaque exécution passe par autant de « gates » que le définit le processus : zéro, un ou plusieurs.

En résumé, le modèle est le suivant : un processus est écrit une seule fois, un événement déclenche une exécution du processus, et cette exécution peut passer par un ou plusieurs points de contrôle avant d’aboutir. Rien ici n’est implicite. La définition du processus est consultable. L’historique de l’exécution est consultable, a posteriori, par toute personne disposant d’un accès. Le point de contrôle, lorsque le processus en comprend un, est un véritable arrêt, et non un point de contrôle souple pouvant être ignoré en cas de charge importante.

C’est aussi ce modèle qui permet de concilier coût et audit. Le coût d’une exécution est attribué à cette exécution spécifique. Son historique d’audit inclut cette même exécution, le plan, les différences, qui a approuvé quoi à chaque porte, et quand. Aucun des deux n’a besoin d’être reconstitué par la suite, les deux sont enregistrés au fur et à mesure de l’exécution.

Ce qui est vrai aujourd’hui, et ce qui va arriver

Point clé : Upsun Dispatch prend aujourd’hui en charge GitHub SaaS et GitLab auto-hébergé comme sources de déclenchement. Le routage par modèle entre les tâches est prévu, mais n’est pas encore disponible.

Upsun Dispatch est indépendant du modèle dans le sens où tu fournis une clé de modèle lors de la configuration, et cette clé s’applique à tous tes processus. Le routage automatique de différentes tâches vers différents modèles, en fonction du coût ou de la qualité, n’est pas encore disponible. C’est prévu, mais pour l’instant, un processus s’exécute sur le modèle que tu as connecté.

Les exemples de déclencheurs utilisés tout au long de cet article, comme l’ouverture d’une pull request ou la mention d’un ticket, fonctionnent de la même manière, que ton dépôt se trouve sur GitHub SaaS ou sur GitLab auto-hébergé ; les deux sont pris en charge aujourd’hui comme sources de déclenchement.

Lance ton premier processus pour voir par toi-même l’historique d’une exécution et ses portes.

Foire aux questions (FAQ)

Un processus, c’est la même chose qu’un agent ?
Non. Un processus peut impliquer un agent qui effectue une tâche à une ou plusieurs étapes, mais le processus est la séquence définie, tandis que l’agent n’est qu’un participant parmi d’autres. Upsun Dispatch considère le processus, et non un agent en particulier, comme l’unité qui est conçue, versionnée et gérée.

Un processus peut-il comporter plusieurs étapes de contrôle ?
Oui. Un processus peut définir autant d’étapes de contrôle que ses étapes l’exigent : aucune, une ou plusieurs, chacune étant transmise à la personne chargée de prendre cette décision spécifique.

Si je modifie la définition d’un processus, est-ce que ça affecte les exécutions déjà en cours ?
Non. Une modification du processus s’applique aux futures exécutions déclenchées après la modification. Une exécution déjà en cours se poursuit selon la définition qui était active au moment de son lancement.