Upsun Dispatch prend en charge le travail depuis la planification jusqu'au code et à la révision, puis le dépose dans ton dépôt GitHub ou GitLab. Ce qui se passe lors de la fusion, c'est ce qui se passe d'habitude : Vercel, AWS, ton propre Kubernetes ou Upsun Cloud.
Tu planifies à un endroit, tu codes à un autre, tu valides dans ton outil Git, puis tu déploies via un pipeline. Rien ne permet de conserver le contexte d’une étape à l’autre, donc chaque étape recommence à zéro.
Les plateformes qui couvrent toutes les étapes, de la planification à la révision, veulent généralement aussi s'occuper du déploiement ; du coup, la façon dont ton équipe travaille avec les agents est étroitement liée à l'endroit où l'application s'exécute.
C'est là que se trouvent tes environnements, tes secrets, ton chemin de restauration et des mois de correctifs accumulés. L'ajout d'une nouvelle couche en amont de la chaîne ne devrait pas impliquer de tout reconstruire à partir de zéro.
Upsun Dispatch fonctionne via ton dépôt. Les tâches arrivent sous forme de ticket ou de spécification, les agents les codent dans des environnements de test isolés, puis la modification est envoyée sous forme de pull request qu'une personne doit valider.
Lors de la fusion, ton dépôt fonctionne comme d’habitude. Le processus de déploiement que tu utilises reste inchangé, car Upsun Dispatch n’intervient pas dans ce processus.
Upsun Dispatch envoie la modification terminée vers ton dépôt sous forme de pull request. Ce qui se passe après la fusion, c'est ce qui s'est déjà passé.
Un problème, un ticket ou un cahier des charges sommaire se transforme en un plan sur lequel un agent peut s'appuyer. Le périmètre, les étapes et les critères d'acceptation sont définis par écrit avant toute exécution.
Les étapes de l'agent s'exécutent dans des environnements isolés et jetables. Aucun élément du processus n'a accès à ton environnement de production ni à tes identifiants de déploiement.
La modification arrive dans ton dépôt sous forme de pull request ou de merge request. Les règles de branche existantes et les vérifications obligatoires s'appliquent, et une personne doit donner son accord avant la fusion.
Lors d’une fusion, ton pipeline s’exécute. GitHub Actions, GitLab CI, l’intégration Git d’un fournisseur, Argo CD ou Flux surveillent le dépôt. Upsun Dispatch n’intervient pas à cette étape.
Ton application s'exécute là où tu choisis de l'exécuter. La manière dont les agents contribuent au code source est une question distincte, et y répondre ne relance pas la première question.
Différents services, différentes cibles, parfois différents fournisseurs. Upsun Dispatch fonctionne de la même manière pour tous les dépôts qui se déploient vers des destinations totalement différentes.
Si Argo CD, Flux ou d’autres outils surveillent déjà ton dépôt, la fusion correspond au déploiement. Upsun Dispatch applique la modification et ton cluster la récupère selon son propre calendrier.
Ton propre matériel est une cible de déploiement comme une autre. Si ton dépôt peut y accéder aujourd’hui, rien ne change à ce sujet.
Les pipelines qui ont mis des mois à être mis au point continuent de fonctionner tels quels. Upsun Dispatch ajoute une phase de planification, de codage et de révision en amont, sans pour autant remplacer ce qui se passe après la fusion.
Tu peux présenter Upsun Dispatch à tes agents sans te soucier de l'hébergement, et te faire une idée rien qu'à partir des trois premières étapes. Cette période d'essai ne t'engage en rien à migrer.
Comment ça marche