{"id":43451,"date":"2021-09-09T09:33:28","date_gmt":"2021-09-09T07:33:28","guid":{"rendered":"https:\/\/kinsta.com\/?p=100242"},"modified":"2025-02-07T15:16:15","modified_gmt":"2025-02-07T14:16:15","slug":"monorepo-vs-multi-repo","status":"publish","type":"post","link":"https:\/\/kinsta.com\/es\/blog\/monorepo-vs-multi-repo\/","title":{"rendered":"Monorepo vs Multi-Repo: Ventajas y Desventajas de las Estrategias de Repositorio de C\u00f3digo"},"content":{"rendered":"

Existen dos estrategias principales para alojar<\/span><\/a> y gestionar el c\u00f3digo a trav\u00e9s de Git: monorepo vs multi-repo. Ambos enfoques tienen sus pros y sus contras.<\/p>\n

Podemos utilizar cualquiera de los dos enfoques para cualquier base de c\u00f3digo en cualquier lenguaje. Puedes utilizar cualquiera de estas estrategias para proyectos que contengan desde un pu\u00f1ado de bibliotecas<\/span><\/a> hasta miles de ellas. Incluso si se trata de unos pocos miembros del equipo o cientos, o si quieres alojar c\u00f3digo privado o de c\u00f3digo abierto, puedes optar por monorepo o multi-repo en funci\u00f3n de varios factores.<\/p>\n

\u00bfCu\u00e1les son las ventajas e inconvenientes de cada enfoque? \u00bfCu\u00e1ndo debemos utilizar uno u otro? Averig\u00fc\u00e9moslo.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

\u00bfQu\u00e9 son los repositorios?<\/h2>\n

Un repo (abreviatura de repositorio) es un almac\u00e9n para todos los cambios y archivos de un proyecto, lo que permite a los desarrolladores \u00abcontrolar la versi\u00f3n\u00bb de los activos del proyecto a lo largo de su etapa de desarrollo.<\/p>\n

Normalmente nos referimos a los repositorios Git<\/span><\/a> (como los que proporcionan GitHub<\/span><\/a>, GitLab<\/span><\/a> o Bitbucket<\/span><\/a>), pero el concepto tambi\u00e9n se aplica a otros sistemas de control de versiones (como Mercurial).<\/p>\n\n

\u00bfQu\u00e9 es un monorrepo?<\/h2>\n

El enfoque monorepo utiliza un \u00fanico repositorio<\/span><\/a> para alojar todo el c\u00f3digo de las m\u00faltiples bibliotecas o servicios que componen los proyectos de una empresa. En su versi\u00f3n m\u00e1s extrema, todo el c\u00f3digo base de una empresa – que abarca varios proyectos y est\u00e1 codificado en diferentes lenguajes – se aloja en un \u00fanico repositorio.<\/p>\n

Los Beneficios de Monorepo<\/h2>\n

Alojar todo el c\u00f3digo base en un \u00fanico repositorio ofrece las siguientes ventajas.<\/p>\n

Reduce las barreras de entrada<\/h3>\n

Cuando los nuevos miembros del personal empiezan a trabajar en una empresa, necesitan descargar el c\u00f3digo e instalar las herramientas necesarias para empezar a trabajar en sus tareas. Supongamos que el proyecto est\u00e1 disperso en muchos repositorios, cada uno con sus instrucciones de instalaci\u00f3n y las herramientas necesarias. En ese caso, la configuraci\u00f3n inicial ser\u00e1 compleja y, en la mayor\u00eda de los casos, la documentaci\u00f3n no estar\u00e1 completa, lo que obligar\u00e1 a estos nuevos miembros del equipo a pedir ayuda a sus colegas.<\/p>\n

Un monorepo simplifica las cosas. Al haber una \u00fanica ubicaci\u00f3n que contiene todo el c\u00f3digo y la documentaci\u00f3n<\/span><\/a>, se puede agilizar la configuraci\u00f3n inicial.<\/p>\n

Gesti\u00f3n centralizada del c\u00f3digo<\/h3>\n

Tener un \u00fanico repositorio da visibilidad de todo el c\u00f3digo a todos los desarrolladores. Simplifica la gesti\u00f3n del c\u00f3digo, ya que podemos utilizar un \u00fanico gestor de incidencias para vigilar todas las incidencias a lo largo del ciclo de vida de la aplicaci\u00f3n.<\/p>\n

Por ejemplo, estas caracter\u00edsticas son valiosas cuando un problema se extiende a dos (o m\u00e1s) bibliotecas hijas con el error existente en la biblioteca dependiente. Con m\u00faltiples repositorios, puede ser un reto encontrar el trozo de c\u00f3digo<\/span><\/a> donde se produce el problema.<\/p>\n

Adem\u00e1s, tendr\u00edamos que averiguar qu\u00e9 repositorio utilizar para crear la incidencia y, a continuaci\u00f3n, invitar y etiquetar a miembros de otros equipos para que ayuden a resolver el problema.<\/p>\n

Sin embargo, con un monorrepo, tanto la localizaci\u00f3n de los problemas del c\u00f3digo como la colaboraci\u00f3n para solucionarlos son m\u00e1s sencillas.<\/p>\n

Refactorizaciones de la aplicaci\u00f3n sin complicaciones<\/h3>\n

Al crear una refactorizaci\u00f3n del c\u00f3digo en toda la aplicaci\u00f3n, se ver\u00e1n afectadas m\u00faltiples bibliotecas. Si las alojas en varios repositorios, la gesti\u00f3n de todos los pull requests para mantenerlos sincronizados entre s\u00ed puede resultar un reto.<\/p>\n

Un monorepo facilita la realizaci\u00f3n de todas las modificaciones de todo el c\u00f3digo de todas las bibliotecas y su env\u00edo bajo un \u00fanico pull request.<\/p>\n

M\u00e1s dif\u00edcil de romper la funcionalidad adyacente<\/h3>\n

Con el monorepo, podemos configurar todas las pruebas de todas las bibliotecas para que se ejecuten cada vez que se modifique alguna de ellas. Como resultado, la probabilidad de hacer un cambio en algunas bibliotecas ha minimizado los efectos adversos en otras bibliotecas.<\/p>\n

Los equipos comparten la cultura del desarrollo<\/h3>\n

Aunque no es imposible, con un enfoque monorrepo, resulta dif\u00edcil inspirar subculturas \u00fanicas entre los distintos equipos. Dado que compartir\u00e1n el mismo repositorio, lo m\u00e1s probable es que compartan las mismas metodolog\u00edas de programaci\u00f3n<\/span><\/a> y gesti\u00f3n y que utilicen las mismas herramientas de desarrollo<\/span><\/a>.<\/p>\n

Problemas con el enfoque monorrepo<\/h2>\n

Utilizar un \u00fanico repositorio para todo nuestro c\u00f3digo tiene varios inconvenientes.<\/p>\n

Ciclos de desarrollo m\u00e1s lentos<\/h3>\n

Cuando el c\u00f3digo de una biblioteca contiene cambios de ruptura, que hacen que las pruebas de las bibliotecas dependientes fallen, el c\u00f3digo tambi\u00e9n debe ser corregido antes de fusionar los cambios.<\/p>\n

Si estas bibliotecas dependen de otros equipos, que est\u00e1n ocupados trabajando en alguna otra tarea y no son capaces (o no est\u00e1n dispuestos) a adaptar su c\u00f3digo para evitar los cambios de ruptura y hacer que las pruebas pasen, el desarrollo de la nueva caracter\u00edstica puede estancarse.<\/p>\n

Es m\u00e1s, es muy posible que el proyecto empiece a avanzar solo a la velocidad del equipo m\u00e1s lento de la empresa. Este resultado podr\u00eda frustrar a los miembros de los equipos m\u00e1s r\u00e1pidos, creando las condiciones para que quieran abandonar la empresa.<\/p>\n

Adem\u00e1s, una biblioteca tendr\u00e1 que ejecutar las pruebas de todas las dem\u00e1s bibliotecas tambi\u00e9n. Cuantas m\u00e1s pruebas haya que ejecutar<\/span><\/a>, m\u00e1s tiempo se tarda en hacerlo, lo que ralentiza la rapidez con la que podemos iterar en nuestro c\u00f3digo.<\/p>\n

Requiere la descarga de todo el c\u00f3digo base<\/h3>\n

Cuando el monorepo contiene todo el c\u00f3digo de una empresa, puede ser enorme y contener gigabytes de datos. Para contribuir a cualquier biblioteca alojada en \u00e9l, cualquiera necesitar\u00eda descargar todo el repositorio.<\/p>\n

Tratar con una amplia base de c\u00f3digo implica un mal uso del espacio en nuestros discos duros e interacciones m\u00e1s lentas con ella. Por ejemplo, acciones cotidianas como ejecutar git status<\/span><\/code> o buscar en la base de c\u00f3digo con una regex pueden tardar muchos segundos o incluso minutos m\u00e1s de lo que tardar\u00edan con m\u00faltiples repos.<\/p>\n

Las bibliotecas no modificadas pueden tener una nueva versi\u00f3n<\/h3>\n

Cuando etiquetamos<\/span><\/a> el monorepo, a todo el c\u00f3digo que contiene se le asigna la nueva etiqueta. Si esta acci\u00f3n desencadena una nueva publicaci\u00f3n, entonces todas las bibliotecas alojadas en el repositorio ser\u00e1n reci\u00e9n publicadas con el n\u00famero de versi\u00f3n de la etiqueta, aunque muchas de esas bibliotecas no hayan tenido ning\u00fan cambio.<\/p>\n

La bifurcaci\u00f3n es m\u00e1s dif\u00edcil<\/h3>\n

Los proyectos de c\u00f3digo abierto deben facilitar al m\u00e1ximo la participaci\u00f3n de los colaboradores. Con m\u00faltiples repositorios, los colaboradores pueden dirigirse directamente al repositorio espec\u00edfico del proyecto al que quieren contribuir. Sin embargo, con un monorepositorio que aloja varios proyectos, los colaboradores deben navegar primero hacia el proyecto correcto y tendr\u00e1n que entender c\u00f3mo su contribuci\u00f3n puede afectar a todos los dem\u00e1s proyectos.<\/p>\n

\u00bfQu\u00e9 es el Multi-Repo?<\/h2>\n

El enfoque multirepo utiliza varios repositorios para alojar las m\u00faltiples bibliotecas o servicios de un proyecto desarrollado por una empresa. En su punto m\u00e1s extremo, alojar\u00e1 cada conjunto m\u00ednimo de c\u00f3digo reutilizable o funcionalidad independiente (como un microservicio) bajo su repositorio.<\/p>\n

Ventajas del Multi-Repo<\/h2>\n

Alojar cada biblioteca de forma independiente de todas las dem\u00e1s proporciona una gran cantidad de ventajas.<\/p>\n

Versionado independiente de bibliotecas<\/h3>\n

Al etiquetar un repositorio, se asigna la etiqueta \u00abnuevo\u00bb a todo tu c\u00f3digo base. Dado que solo el c\u00f3digo de una biblioteca espec\u00edfica est\u00e1 en el repositorio, la biblioteca puede ser etiquetada y versionada independientemente de todas las dem\u00e1s bibliotecas alojadas en otros lugares.<\/p>\n

Tener una versi\u00f3n independiente para cada librer\u00eda ayuda a definir el \u00e1rbol de dependencias de la aplicaci\u00f3n, permiti\u00e9ndonos configurar qu\u00e9 versi\u00f3n de cada librer\u00eda utilizar.<\/p>\n

Comunicados de servicio independientes<\/h3>\n

Dado que el repositorio solo contiene el c\u00f3digo de alg\u00fan servicio y nada m\u00e1s, puedes tener tu propio ciclo de despliegue, independientemente de los avances de las aplicaciones que acceden a \u00e9l.<\/p>\n

El servicio puede utilizar un ciclo de liberaci\u00f3n r\u00e1pido, como la entrega continua (donde el nuevo c\u00f3digo se despliega despu\u00e9s de pasar todas las pruebas). Algunas bibliotecas que acceden al servicio pueden utilizar un ciclo de lanzamiento m\u00e1s lento, como las que solo producen una nueva versi\u00f3n una vez a la semana.<\/p>\n

Ayuda a definir el control de acceso en toda la organizaci\u00f3n<\/h3>\n

Solo los miembros del equipo implicados en el desarrollo de una librer\u00eda necesitan a\u00f1adirse al repositorio correspondiente y descargar su c\u00f3digo. Como resultado, hay una estrategia impl\u00edcita de control de acceso para cada capa de la aplicaci\u00f3n<\/span><\/a>. Aquellos involucrados con la biblioteca tendr\u00e1n derechos de edici\u00f3n, y todos los dem\u00e1s pueden no tener acceso al repositorio. O puede que se les den derechos de lectura pero no de edici\u00f3n.<\/p>\n

Permite a los equipos trabajar de forma aut\u00f3noma<\/h3>\n

Los miembros del equipo pueden dise\u00f1ar la arquitectura de la biblioteca e implementar su c\u00f3digo trabajando de forma aislada de todos los dem\u00e1s equipos. Pueden tomar decisiones basadas en lo que hace la biblioteca en el contexto general sin verse afectados por los requisitos espec\u00edficos de alg\u00fan equipo o aplicaci\u00f3n externa.<\/p>\n

Problemas con el enfoque Multir-Repo<\/h2>\n

El uso de m\u00faltiples repositorios puede dar lugar a varios problemas.<\/p>\n

Las bibliotecas deben resintonizarse constantemente<\/h3>\n

Cuando se publique una nueva versi\u00f3n de una biblioteca que contenga cambios de ruptura, las bibliotecas que dependan de ella tendr\u00e1n que adaptarse para empezar a utilizar la \u00faltima versi\u00f3n. Si el ciclo de publicaci\u00f3n de la biblioteca es m\u00e1s r\u00e1pido que el de sus bibliotecas dependientes, \u00e9stas podr\u00edan quedar r\u00e1pidamente desincronizadas entre s\u00ed.<\/p>\n

Los equipos tendr\u00e1n que ponerse al d\u00eda constantemente para utilizar las \u00faltimas versiones de otros equipos. Dado que los distintos equipos tienen diferentes prioridades, esto puede resultar a veces arduo de conseguir.<\/p>\n

En consecuencia, un equipo que no sea capaz de ponerse al d\u00eda puede acabar ci\u00f1\u00e9ndose a la versi\u00f3n anticuada de la biblioteca de la que depende. Este resultado tendr\u00e1 implicaciones en la aplicaci\u00f3n (en t\u00e9rminos de seguridad, velocidad y otras consideraciones), y la brecha en el desarrollo a trav\u00e9s de las bibliotecas solo puede aumentar.<\/p>\n

Puede fragmentar los equipos<\/h3>\n

Cuando los diferentes equipos no necesitan interactuar, pueden trabajar en sus propios silos. A largo plazo, esto puede dar lugar a que los equipos produzcan sus subculturas dentro de la empresa, como el empleo de diferentes metodolog\u00edas de programaci\u00f3n o gesti\u00f3n o la utilizaci\u00f3n de diferentes conjuntos de herramientas de desarrollo.<\/p>\n

Si alg\u00fan miembro del equipo tiene que trabajar finalmente en un equipo diferente, puede sufrir un peque\u00f1o choque cultural y aprender una nueva forma de hacer su trabajo<\/span>.<\/p>\n

Monorepo vs Multi-Repo: Principales diferencias<\/h2>\n

Ambos enfoques se ocupan, en \u00faltima instancia, del mismo objetivo: gestionar el c\u00f3digo base. Por lo tanto, ambos deben resolver los mismos retos, como la gesti\u00f3n de las versiones, el fomento de la colaboraci\u00f3n entre los miembros del equipo<\/span><\/a>, la gesti\u00f3n de los problemas y la ejecuci\u00f3n de las pruebas, entre otros.<\/p>\n

Su principal diferencia radica en el momento en que los miembros del equipo deben tomar decisiones: por adelantado en el caso de los monorepos o por debajo de la l\u00ednea en el caso de los multi-repos.<\/p>\n

Analicemos esta idea con m\u00e1s detalle.<\/p>\n

Dado que todas las bibliotecas se versionan de forma independiente en el multi-repo, un equipo que libere una biblioteca con cambios de ruptura puede hacerlo de forma segura asignando un nuevo n\u00famero de versi\u00f3n principal a la \u00faltima versi\u00f3n. Otros grupos pueden hacer que sus bibliotecas dependientes se ci\u00f1an a la versi\u00f3n antigua y cambien a la nueva una vez adaptado su c\u00f3digo.<\/p>\n

Este enfoque deja la decisi\u00f3n de cu\u00e1ndo adaptar todas las dem\u00e1s bibliotecas a cada equipo responsable, que puede hacerlo en cualquier momento. Si lo hacen demasiado tarde y se publican nuevas versiones de las bibliotecas, cerrar la brecha entre ellas ser\u00e1 cada vez m\u00e1s dif\u00edcil.<\/p>\n

En consecuencia, mientras que un equipo puede iterar r\u00e1pidamente y con frecuencia en su c\u00f3digo, otros equipos pueden resultar incapaces de ponerse al d\u00eda, produciendo finalmente bibliotecas divergentes.<\/p>\n

Por otro lado, en un entorno monorepo, no podemos liberar una nueva versi\u00f3n de una biblioteca que rompa alguna otra biblioteca, ya que tus pruebas fallar\u00e1n. En este caso, el primer equipo debe comunicarse con el segundo para incorporar los cambios.<\/p>\n

Este enfoque obliga a los equipos a adaptar todas las bibliotecas<\/span><\/a> en conjunto cada vez que haya que hacer un cambio en una sola biblioteca. Todos los equipos se ven obligados a hablar entre s\u00ed y llegar a una soluci\u00f3n conjunta.<\/p>\n

Como resultado, el primer equipo no podr\u00e1 iterar tan r\u00e1pido como desea, pero el c\u00f3digo de las diferentes bibliotecas no empezar\u00e1 a divergir en ning\u00fan momento.<\/p>\n

En resumen, el enfoque multi-repo puede ayudar a crear una cultura de \u00abmoverse r\u00e1pido y romper cosas\u00bb entre los equipos, donde los equipos \u00e1giles e independientes pueden producir sus resultados a su velocidad. En cambio, el enfoque monorrepo favorece una cultura de concienciaci\u00f3n y cuidado, en la que los equipos no deben quedarse atr\u00e1s para resolver un problema por s\u00ed solos.<\/p>\n

Enfoque h\u00edbrido Poly-As-Mono<\/h2>\n

Si no podemos decidir si utilizar el enfoque multi-repo o monorepo, tambi\u00e9n existe el enfoque intermedio: utilizar m\u00faltiples repositorios y emplear alguna herramienta para mantenerlos sincronizados, asemej\u00e1ndose a un monorepo pero con m\u00e1s flexibilidad.<\/p>\n

Meta<\/a> <\/span>es una de esas herramientas. Organiza m\u00faltiples repositorios en subdirectorios y proporciona una interfaz de l\u00ednea de comandos<\/span><\/a> que ejecuta el mismo comando en todos ellos simult\u00e1neamente.<\/p>\n

Un meta-repositorio contiene la informaci\u00f3n sobre los repositorios que componen un proyecto. La clonaci\u00f3n de este repositorio a trav\u00e9s del meta-repositorio clonar\u00e1 recursivamente todos los repositorios necesarios, facilitando que los nuevos miembros del equipo puedan empezar a trabajar en sus proyectos inmediatamente.<\/p>\n

Para clonar un meta-repositorio y todos tus repositorios m\u00faltiples definidos, debemos ejecutar lo siguiente:<\/p>\n

meta git clone [meta repo url]\n<\/code><\/pre>\n
Meta ejecutar\u00e1 un git clone<\/span><\/code> para cada repositorio y lo colocar\u00e1 en una subcarpeta:<\/p>\n
\"Clonaci\u00f3n<\/a>
Clonaci\u00f3n de un metaproyecto. (Fuente de la imagen: github.com\/mateodelnorte\/meta<\/a>)<\/figcaption><\/figure>\n
A partir de ah\u00ed, al ejecutar el comando meta exec<\/span><\/code> se ejecutar\u00e1 el comando en cada subcarpeta. Por ejemplo, ejecutar git checkout master<\/span><\/code> en cada repositorio se hace as\u00ed:<\/p>\n
meta exec \"git checkout master\"\n<\/code><\/pre>\n
Enfoque h\u00edbrido Mono-As-Poly<\/h2>\n
Otro enfoque es gestionar el c\u00f3digo a trav\u00e9s de un monorepo para el desarrollo, pero copiando el c\u00f3digo de cada biblioteca en tu repositorio independiente para el despliegue.<\/p>\n
Esta estrategia es frecuente en el ecosistema PHP porque Packagist<\/span><\/a> (el repositorio principal de Composer<\/span><\/a>) requiere una URL<\/span><\/a> de<\/span> repositorio p\u00fablico para publicar un paquete, y no es posible indicar que el paquete se encuentra dentro de un subdirectorio del repositorio.<\/p>\n
Dada la limitaci\u00f3n de Packagist, los proyectos de PHP pueden seguir utilizando un monorepo para el desarrollo<\/span><\/a>, pero deben utilizar el enfoque multi-repo para el despliegue.<\/p>\n
Para lograr esta conversi\u00f3n, podemos ejecutar un script con <\/span>git subtree split<\/span><\/code><\/a> o utilizar una de las herramientas disponibles que realizan la misma l\u00f3gica:<\/p>\n