Polyrepo (multirepo)
En un esquema polyrepo cada aplicación o librería tiene su propio repositorio, con su propia historia, su pipeline y su ciclo de releases.
En un polyrepo, también llamado multirepo, cada proyecto está aislado a nivel de repositorio. Un equipo clona solo lo que le pertenece. Cada repositorio tiene su propio pipeline, sus propias versiones de dependencias y sus propias reglas de acceso. El código compartido viaja como paquetes versionados a través de un registro como npm.
Esto coincide con la estructura que ya tienen muchas organizaciones, y no requiere herramientas especiales para empezar.
Ejemplo
Una plataforma tiene cinco repositorios: shell, orders, invoices, design-system y auth-lib. El equipo del sistema de diseño publica una nueva versión menor de @acme/ui en el registro interno. El equipo de pedidos actualiza cuando está listo, cambiando la versión en su package.json. El equipo de facturas se queda un mes más en la versión anterior.
Confusión frecuente
Se suele equiparar repositorios separados con equipos independientes. El acoplamiento sigue existiendo. Se traslada del código fuente a las versiones de paquetes y a los contratos en tiempo de ejecución. En el ejemplo anterior, producción corre ahora dos versiones del sistema de diseño a la vez. En un esquema federado eso puede significar dos copias de la librería en el navegador, o un conflicto de versiones en tiempo de ejecución.
Los cambios transversales también son más lentos. Un cambio incompatible en una librería compartida requiere un release y luego un pull request en cada consumidor, y nadie ve el impacto completo en un solo lugar. Los equipos que eligen polyrepo necesitan automatización para esto: bots de actualización de dependencias, una plantilla de pipeline compartida y un reporte de qué versión corre cada aplicación.
Ningún modelo es mejor en general. La elección depende de la cantidad de equipos, de cuánto código se comparte y de cuánta autonomía necesita cada equipo. En microfrontends se ve cómo funcionan ambos esquemas en una plataforma.
Por qué importa. La organización de los repositorios define cómo llegan las librerías compartidas y los contratos a cada microfrontend. En una migración, también define si el código legacy y el nuevo se pueden cambiar juntos o solo mediante paquetes publicados.
Términos relacionados
¿Planeas una migración o una plataforma de microfrontends?
En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.
Escríbeme por LinkedIn