1. Entrée
Le ticket arrive dans votre gestionnaire. N'importe qui peut l'écrire : des modèles en langage simple permettent de signaler un problème, de demander une nouveauté ou de modifier l'existant.
D'un ticket écrit en langage courant à un changement déployé, avec les arrêts humains que vous décidez. Voici ce qui se passe entre les deux.
Huit états, chacun avec son responsable. Le moteur avance seul, sauf là où vous avez posé une barrière.
Le ticket arrive dans votre gestionnaire. N'importe qui peut l'écrire : des modèles en langage simple permettent de signaler un problème, de demander une nouveauté ou de modifier l'existant.
Un agent lit le ticket et explore votre code en lecture seule. Il décide s'il est prêt à être implémenté, évalue sa complexité et détermine quels composants il touche et dans quel ordre.
Si quelque chose est ambigu, le ticket se bloque et pose la question. Des questions numérotées, en langage simple et avec des options concrètes, qui précisent aussi ce qui a bien été compris. Il ne demande jamais ce qu'il peut découvrir en lisant le code.
Un agent travaille sur une branche isolée : il écrit le code, exécute les tests et la compilation de votre projet, corrige ce qui casse et ajoute les tests dont le changement a besoin.
La proposition de changement est ouverte avec le travail terminé. En cas de conflits à l'intégration, ils sont détectés et expliqués dans le ticket en langage compréhensible.
Le ticket attend une personne. Cet arrêt n'est pas assuré par un modèle : la revue de qualité vous appartient, et sans elle rien n'avance.
Vous décidezUne fois le changement approuvé, vous décidez quand il sort. La promotion en production est une décision humaine, pas automatique.
Vous décidezLa branche est promue en production et le ticket se ferme. Votre propre système d'intégration continue continue d'assurer le déploiement : il n'y a rien à migrer.
Un système qui travaille seul doit savoir s'arrêter.
Si un ticket échoue plusieurs fois de suite, il cesse d'essayer et demande une revue humaine. Quand une personne le débloque, le compteur repart à zéro.
Si l'agent n'a produit aucun changement réel, le ticket se bloque au lieu d'être considéré comme terminé.
Si votre revue rejette le travail, la nouvelle tentative se fait avec un modèle plus performant au lieu de répéter la même chose.
Vous répondez à la question en commentant le ticket, par Telegram ou depuis le portail, et le travail reprend exactement à la phase où il s'était arrêté.
L'état de chaque ticket, la file de ce qui vous attend, la dépense par exécution et l'historique du travail.
E-mail et Telegram quand quelque chose se bloque ou est prêt pour votre revue, dans la langue de votre projet.
Chaque exécution enregistre quel modèle a été utilisé, combien de tours elle a pris et combien elle a coûté. La transcription intégrale est conservée quatre-vingt-dix jours, puis s'efface d'elle-même.
Plafond par ticket, plafond quotidien et nombre maximal de tickets par jour, dans votre fuseau horaire. Quand votre limite coexiste avec la nôtre, la plus restrictive l'emporte.
Le moyen le plus rapide de le comprendre est de le voir travailler sur votre propre code.
