Automatiser la maintenance des fourches, un travail dont personne ne veut

La plupart des organisations exécutant des logiciels importants ont au moins un fork qu’elles souhaiteraient ne pas avoir. Une bibliothèque corrigée pour une exigence en amont ne prendrait pas. Une dépendance vendue avec des modifications locales. Quelque chose a été créé il y a trois ans pour une raison que personne ici présent ne peut expliquer complètement.

Le travail de maintien à jour est la définition d’une tâche importante et jamais urgente, ce qui signifie qu’elle se déroule dans des élans de culpabilité.

Pourquoi cette tâche convient

La plupart des tâches d'agent proposées échouent à l'un des trois tests. Celui-ci les dépasse tous.

C’est bien précisé. Prendre les modifications en amont, les appliquer à un arbre avec des modifications locales connues, résoudre les conflits mécaniques, lancer les tests.

Il a un point de révision naturel. Le résultat est une pull request, et en examiner une est déjà quelque chose que les ingénieurs font.

C’est délimité. Il existe un ensemble défini de validations en amont et une arborescence définie, de sorte que l'agent ne peut pas errer indéfiniment.

Comparez cela à « traiter les demandes des clients », qui échoue dans les trois cas, et la différence dans les résultats n'est pas mystérieuse.

Ce que l'agent devrait et ne devrait pas faire

Il doit appliquer les modifications mécaniques, résoudre les conflits lorsque la résolution découle de la structure du changement, exécuter la suite de tests et rédiger une description de ce qu'il a fait et des conflits qu'il a résolus et comment.

Il ne doit pas décider qu'un test échoué est acceptable, abandonner silencieusement une modification locale parce qu'elle est en conflit, ou élargir sa portée pour inclure le refactor qu'il a remarqué en cours de route.

Le dernier point compte plus qu’il n’y paraît. Un agent qui améliore des choses qu’il n’a pas été demandé d’améliorer produit des demandes d’extraction plus difficiles à examiner que le travail qu’il a remplacé.

Là où est la vraie difficulté

Pas dans l'application de correctifs. En sachant quelles modifications locales sont porteuses.

Un fork accumule des changements, dont certains sont délibérés et d'autres sont des accidents que personne n'a supprimés. Un agent ne peut pas faire la différence à partir du code seul, et une résolution de conflit qui rejette discrètement un changement délibéré est l’échec qui coûte le plus cher.

L'atténuation est une documentation de l'intention : un enregistrement de la raison pour laquelle chaque modification locale existe, conservé parallèlement au fork. Les organisations qui disposent de ce système obtiennent des résultats nettement meilleurs, et l’exercice de rédaction est généralement précieux en soi.

L'évaluer

Les critères utiles sont spécifiques. La suite de tests a-t-elle réussi ? Toutes les modifications locales ont-elles été préservées ou explicitement signalées comme supprimées avec une raison. Le champ d'application s'est-il limité aux changements en amont. La description est-elle exacte par rapport au diff.

Ceux-ci sont tous vérifiables automatiquement, ce qui permet aux évaluateurs de noter chaque exécution plutôt qu'à une personne d'examiner chaque exécution avec le même soin.

Le résultat honnête

Cela n’élimine pas le travail. Cela passe d'une journée d'effort mécanique à une heure de révision, et cela rend la cadence régulière plutôt qu'occasionnelle, ce qui constitue l'essentiel des avantages. Les petites fusions fréquentes sont considérablement plus faciles que le rattrapage annuel.

Suivant

Les pages de Software Factory expliquent comment le travail en retard devient des demandes d'extraction prêtes à être examinées. Les pages du système d'orchestration d'agent couvrent l'évaluation, la politique et l'attribution des coûts.