Más de 110 PR en cola, despachados en 30 horas

Problema

Reeve es una plataforma de crecimiento para comercio con IA, y su MVP esperaba en una cola de más de 110 pull requests repartidos en 4 repositorios. Yo hacía de gate de releases de Reeve, así que vaciar esa cola era mi trabajo, sin dejar que la velocidad rebajara el listón de lo que llega a producción.

Una cola de ese tamaño se estorba a sí misma. Cada merge mueve la base bajo los pull requests que vienen detrás.

Enfoque

Dividí el trabajo en dos: preparación en paralelo, admisión en serie.

1. 01Cola110+ PR en 4 repos
2. 02Agentesun worktree cada uno
3. 03Gatetests en cada merge
4. 04Fusionados110+ en ~30 h

1. 01Más de 110 pull requests esperaban en 4 repositorios, y cada merge movía la base bajo los demás.
2. 02Agentes de Claude Code, cada uno en su propio git worktree, prepararon los pull requests y apilaron los cambios dependientes en cadenas.
3. 03De uno en uno, cada pull request pasó un merge gate serial que ejecutaba los tests sobre el resultado del merge.
4. 04La cola entera quedó vacía en unas 30 horas. Los agentes pusieron la velocidad; el gate mantuvo el listón.

Paso 1 de 4

Más de 110 pull requests esperaban en 4 repositorios, y cada merge movía la base bajo los demás.

La preparación fue en paralelo. Cada agente de Claude Code trabajó en su propio git worktree aislado, así que nunca se pisaron entre sí. Agruparon los cambios dependientes en cadenas de PR apiladas que podían entrar en orden.

La admisión siguió siendo serial. Cada pull request pasó un merge gate antes de fusionarse: los tests se ejecutaban sobre cada resultado de merge, en una réplica del CI en Docker dividida en shards. Por el camino corregí también hallazgos de seguridad.

Resultado

La cola entera, más de 110 pull requests, quedó vacía en unas 30 horas. Los agentes aportaron el rendimiento; el gate serial, la seguridad.

Es el mismo papel que cumplía a diario como gate de releases de Reeve: más de 1.900 pull requests fusionados, la mayoría de compañeros del equipo.