Uber lanza SubmitQueue, una cola de fusión especulativa de alto rendimiento
Uber SubmitQueue: a high-performance speculative merge queue
Uber ha presentado SubmitQueue, una cola de fusión especulativa de alto rendimiento diseñada para mantener el tronco principal consistentemente verde a escala. La herramienta permite probar múltiples cambios de forma especulativa antes de fusionarlos, reduciendo los conflictos y acelerando el ciclo de desarrollo. Disponible en GitHub, SubmitQueue se integra con el flujo de trabajo existente y promete mejorar la eficiencia en equipos grandes.
SubmitQueue es una cola de fusión especulativa de alto rendimiento que mantiene tu tronco consistentemente verde a escala.
- esprehn
Airbnb tiene una versión interna de esto que era bastante impresionante, llamada Evergreen, basada también en el artículo de Uber.
Ojalá más empresas liberaran su infraestructura de monorepo. Un monorepo bien hecho es un multiplicador de fuerza enorme en una organización grande, pero al mundo del software libre le falta mucha de esa infraestructura, así que todos empiezan desde un punto doloroso y van mejorando, o tienen una mala impresión de los monorepos. Piper, de Google, es otro ejemplo donde liberar el código o venderlo habría hecho maravillas por la industria. En una era de agentes que aterrizan código muy rápido, Piper ha escalado muy bien porque ya estaba a una velocidad de commits inimaginable, mientras que todos los demás intentan reconstruir el control de versiones para mantenerse al día.
- sdfhbdf
Estoy leyendo el repositorio y estoy un poco desconcertado sobre cuál es la innovación.
> SubmitQueue rebasa y valida especulativamente múltiples cambios en paralelo contra estados futuros predichos de HEAD. Cuando las validaciones pasan, los cambios se integran automáticamente. Cuando fallan, SubmitQueue aísla el cambio infractor y reintenta el resto, todo sin intervención humana.
Esto parece ser una característica de GitHub (la tenemos en una instalación antigua de servidor empresarial) que hace lo mismo:
> Cuando una solicitud de extracción se agrega a la cola de fusión, los cambios en la solicitud de extracción se agrupan en un merge_group con la última versión de la rama base, así como los cambios de las solicitudes de extracción que están delante en la cola. GitHub fusionará todos estos cambios en la rama base una vez que pasen las comprobaciones requeridas por las protecciones de rama de la rama base.
https://docs.github.com/en/repositories/configuring-branches...
Entiendo que no todo el mundo usa GitHub, pero estoy bastante seguro de que otros proveedores también tienen características similares, por ejemplo https://docs.gitlab.com/ci/pipelines/merge_trains/#enforce-m...
Entonces, ¿qué tiene de diferente o especial lo de Uber?
- kccqzy
Mantener tu tronco consistentemente verde a escala probablemente sea demasiado costoso. Ni siquiera Google puede mantener su monorepo google3 constantemente compilable, y mucho menos verde. Vale más la pena mantener el tronco mayormente verde, dejar de perseguir el último 0.1%, y en su lugar desarrollar herramientas para identificar rápidamente a los culpables para revertirlos automáticamente.
- jedberg
Creo que la solución al problema de coordinación es una buena herramienta de monorepo (como la del artículo) más IA para entender todo el código base y ayudar a los ingenieros a entender cómo encaja su parte.
Fui uno de los mayores defensores de los microservicios, hasta el punto de viajar por el mundo difundiendo el evangelio de los microservicios como orador principal en grandes conferencias tecnológicas. Creía que los microservicios eran la mejor solución para escalar grandes equipos de desarrolladores, para que equipos pequeños pudieran trabajar en problemas pequeños, donde la API era el único contrato entre ellos.
Pero incluso entonces advertí que la sobrecarga hacía que no valiera la pena para equipos pequeños: que era una solución al problema de coordinación para organizaciones grandes. Y que Google no era un contraejemplo porque habían gastado muchos recursos en su herramienta de monorepo.
Pero hay un nuevo factor en juego que cambia el cálculo:
Las IAs pueden comprender monorepos mucho más fácilmente que un conjunto de microservicios. Las IAs cambian el cálculo aquí. Permiten al desarrollador trabajar con éxito incluso en los monorepos más grandes, y las propias IAs darán mejores resultados cuando todo el código esté en un solo lugar.
- wasmperson
Alternativamente: no te preocupes por mantener el tronco "verde" en absoluto. Ten una segunda rama llamada "estable" o algo así que se adelante automáticamente al último tronco siempre que el tronco esté verde. Haz checkout de estable, empuja nuevos cambios al tronco, evita romper la CI, pero si rompes la CI no te preocupes, solo empuja una corrección.
Si tratas el tronco como algo "sagrado" que siempre debe estar listo para desplegar, terminas con un montón de ramas de larga duración y solicitudes de extracción y todos los conflictos de fusión y la sobrecarga que conllevan.