Automatizar el mantenimiento de las horquillas, un trabajo que nadie quiere

La mayoría de las organizaciones que ejecutan software importante tienen al menos una bifurcación que desearían no tener. Una biblioteca parcheada para un requisito ascendente no aceptaría. Una dependencia proporcionada con modificaciones locales. Algo se bifurcó hace tres años por una razón que ninguno de los presentes puede explicar del todo.

El trabajo de mantenerlo actualizado es la definición de una tarea que es importante y nunca urgente, lo que significa que ocurre en arrebatos de culpa.

Por qué encaja esta tarea

La mayoría de las tareas de agente propuestas no superan una de tres pruebas. Este los pasa todos.

Está bien especificado. Tome los cambios anteriores, aplíquelos a un árbol con modificaciones locales conocidas, resuelva los conflictos mecánicos y ejecute las pruebas.

Tiene un punto de revisión natural. El resultado es una solicitud de extracción y revisar una ya es algo que hacen los ingenieros.

Está acotado. Hay un conjunto definido de confirmaciones ascendentes y un árbol definido, por lo que el agente no puede vagar indefinidamente.

Compare eso con "atender las consultas de los clientes", que falla en los tres, y la diferencia en los resultados no es misteriosa.

Lo que el agente debe y no debe hacer

Debe aplicar los cambios mecánicos, resolver conflictos cuya resolución se derive de la estructura del cambio, ejecutar el conjunto de pruebas y escribir una descripción de lo que hizo, qué conflictos resolvió y cómo.

No debe decidir que una prueba fallida es aceptable, descartar silenciosamente una modificación local porque entró en conflicto o ampliar su alcance para incluir la refactorización que notó en el camino.

Este último importa más de lo que parece. Un agente que mejora cosas que no se le pidió que mejorara produce solicitudes de extracción que son más difíciles de revisar que el trabajo que reemplazó.

¿Dónde está la verdadera dificultad?

No en la aplicación de parches. En saber qué modificaciones locales son portantes.

Una bifurcación acumula cambios, algunos de los cuales son deliberados y otros son accidentes que nadie eliminó. Un agente no puede diferenciar el código por sí solo, y una resolución de conflicto que descarte silenciosamente un cambio deliberado es el fracaso que cuesta más.

La mitigación es la documentación de la intención: un registro de por qué existe cada modificación local, mantenido junto con la bifurcación. Las organizaciones que lo tienen obtienen resultados sustancialmente mejores y el ejercicio de redactarlo suele ser valioso por sí solo.

Evaluandolo

Los criterios útiles son específicos. ¿Pasó el conjunto de pruebas? ¿Se conservaron todas las modificaciones locales o se marcaron explícitamente como eliminadas con un motivo? ¿Se limitó el alcance a los cambios ascendentes? ¿La descripción es precisa en comparación con la diferencia?

Todos ellos se pueden verificar automáticamente, lo que permite a los evaluadores calificar cada ejecución en lugar de que una persona revise cada ejecución con el mismo cuidado.

El resultado honesto

No elimina el trabajo. Lo cambia de un día de esfuerzo mecánico a una hora de repaso, y hace que la cadencia sea regular en lugar de ocasional, que es donde está la mayor parte del beneficio. Las fusiones pequeñas y frecuentes son muchísimo más fáciles que la puesta al día anual.

Siguiente

Las páginas de Software Factory cubren cómo el trabajo pendiente se convierte en solicitudes de extracción listas para revisión. Las páginas del Sistema de orquestación de agentes cubren evaluación, políticas y atribución de costos.