Présentation de la Software Factory Yaju : du backlog à la pull request

Chaque équipe d'ingénieurs dispose de la même pile silencieuse. Pas le travail intéressant, ni le travail urgent non plus : les tickets clairs, petits et qui ne valent jamais vraiment un sprint. La bosse des dépendances qui touche une quarantaine de fichiers. Le point de terminaison qui nécessite la même validation que les six autres. Le test, personne n'a écrit car la fonctionnalité a été livrée un vendredi.

C’est dans cette pile que commence la Software Factory.

Ce que ça fait réellement

Vous le pointez vers un élément du retard. Il lit le problème, lit la base de code qui l'entoure, élabore un plan, écrit la modification, exécute les tests et ouvre une pull request avec une description de ce qu'il a fait et pourquoi. Une personne examine cette pull request exactement comme elle examinerait celle d’un collègue.

Cette dernière phrase représente toute la conception. La Software Factory ne fusionne pas. Il ne décide pas qu’un échec à un test est acceptable. Il n’étend pas tranquillement son champ d’action à partir du ticket qui lui a été donné. Cela produit quelque chose qu’un humain peut juger, puis cela s’arrête.

Pourquoi il se trouve sur le système d'orchestration d'agent

Nous aurions pu le proposer en tant qu'outil autonome. Il en existe de nombreux, et la plupart d’entre eux font de superbes démonstrations. Le problème apparaît au cours de la troisième semaine, lorsque vous en avez quarante répartis dans six équipes et que personne ne peut répondre à trois questions : qu'ont-ils changé, combien ont-ils coûté et qui est responsable de celui qui vient de toucher le service de facturation.

En s'appuyant sur le système d'orchestration d'agents, ces questions ont déjà des réponses. Chaque exécution effectuée par Software Factory est un agent exécuté comme les autres, ce qui signifie qu'il hérite des éléments que nous avons passé trois générations à construire :

• Dépenses attribuées par agent, déclarées en devise plutôt qu'en jetons, afin qu'une équipe puisse voir ce que coûte réellement l'automatisation de son backlog par changement fusionné.
• Des budgets qui arrêtent un dépassement au moment où il se produit, avec un avertissement à l'approche de la limite et un blocage définitif lorsqu'elle est atteinte.
• Politique appliquée au moment de l'action, de sorte qu'un agent qui ne devrait jamais toucher aux informations d'identification de production ne peut pas les toucher, indépendamment de ce que dit le plan.
• Évalue à chaque exécution, notant le résultat par rapport à des critères de comportement, de structure, de latence et de coût, et interrompant l'exécution en cas d'échec d'une vérification.
• Une piste d'audit complète, de sorte que la réponse à la question « pourquoi ce changement s'est produit » est un enregistrement plutôt qu'une reconstruction.

Rien de tout cela n’est une fonctionnalité de Software Factory. C’est une caractéristique de la plate-forme située en dessous, et c’est là le point.

La partie que les gens sous-estiment

Le problème difficile de la génération automatisée de code était de ne jamais générer le code. Les modèles sont capables d’écrire une fonction plausible depuis un certain temps déjà. Le problème difficile concerne tout ce qui entoure la génération : savoir quel ticket peut être remis en toute sécurité, maintenir l'agent à l'intérieur de la limite que vous avez définie, détecter le changement qui est techniquement correct et contextuellement erroné, et être capable de prouver par la suite ce qui s'est passé.

Les équipes qui sautent cette partie obtiennent un départ rapide et une année lente. Le résultat arrive rapidement, et quelqu'un doit alors tout lire très attentivement, pour toujours, car il n'y a aucune raison systématique de faire confiance à une exécution particulière plus qu'à une autre. Les évaluations sont ce qui transforme cela en un processus gérable. Lorsque chaque analyse est évaluée en fonction des critères que vous avez définis, l'examen cesse d'être une suspicion uniforme et commence à être un tri.

Commencer petit, exprès

Les équipes qui en profitent le plus ne sont pas celles qui ont pointé tout leur retard dès le premier jour. Ils ont choisi une catégorie de travail bien spécifiée et à faibles enjeux, l’ont exécutée jusqu’à ce que les résultats d’évaluation soient ennuyeux, puis ont élargi les limites.

C'est plus lent que ce que suggère la démo. C’est également la seule version que nous avons vue résister au-delà du premier mois.

Où ça court

La Software Factory s'exécute partout où le reste de votre déploiement Yaju s'exécute. Si votre code ne peut pas quitter votre infrastructure, il s'exécute de manière auto-hébergée, dans votre propre cloud ou entièrement isolé, avec la même gouvernance appliquée à chaque agent. Les informations d'identification sont résolues au moment de l'exécution à partir du coffre-fort au niveau de l'organisation, de sorte que l'agent ne voit jamais un secret en texte clair et que vous n'avez jamais de clé résidant dans un fichier de configuration.

Essayez-le

La Software Factory est disponible dès maintenant. Si vous souhaitez le voir par rapport à votre propre backlog plutôt qu'à un exemple de référentiel, réservez une démo et nous la parcourirons avec votre code et vos contraintes. Si vous préférez lire en premier, les pages du système d'orchestration d'agent couvrent les couches de gouvernance, de coût et d'évaluation sur lesquelles il repose.