Monorepo vs Multi-Repo: Pros y contras de las estrategias de repositorio de código

Hay dos estrategias principales para alojar y administrar código a través de Git: monorepo vs multi-repo. Ambos enfoques tienen sus pros y sus contras.

Podemos usar cualquier enfoque para cualquier código base en cualquier idioma. Puede utilizar cualquiera de estas estrategias para proyectos que contengan un puñado de bibliotecas para miles de ellas. Incluso si involucra a algunos miembros del equipo o cientos, o si desea alojar código privado o de fuente abierta, aún puede optar por monorepo o multi-repo en función de varios factores.

¿Cuáles son los beneficios y las desventajas de cada enfoque? ¿Cuándo debemos usar uno u otro? ¡Vamos a averiguar!

¿Qué son los repos?

Un repositorio (abreviatura de repositorio) es un almacenamiento para todos los cambios y archivos de un proyecto, lo que permite a los desarrolladores «controlar la versión» de los activos del proyecto a lo largo de su etapa de desarrollo.

Por lo general, nos referimos a los repositorios de Git (proporcionados por GitHub, GitLab o Bitbucket), pero el concepto también se aplica a otros sistemas de control de versiones (como Mercurial).

Hay dos estrategias principales para alojar y administrar nuestra base de código a través de Git: el enfoque monorepo y el enfoque de repositorios múltiples. 🚀 Explore cada uno en esta guía ⬇️Haz clic para tuitear

¿Qué es un Monorepo?

El enfoque de monorepo utiliza un único repositorio para alojar todo el código de las múltiples bibliotecas o servicios que componen los proyectos de una empresa. En su forma más extrema, todo el código base de una empresa, que abarca varios proyectos y está codificado en diferentes idiomas, se aloja en un único repositorio.

Beneficios de Monorepo

Alojar toda la base de código en un solo repositorio proporciona los siguientes beneficios.

Reduce las barreras de entrada

Cuando los nuevos miembros del personal comienzan a trabajar para una empresa, deben descargar el código e instalar las herramientas necesarias para comenzar a trabajar en sus tareas. Suponga que el proyecto está disperso en muchos repositorios, cada uno de los cuales tiene sus instrucciones de instalación y herramientas necesarias. En ese caso, la configuración inicial será compleja y, la mayoría de las veces, la documentación no estará completa, lo que requerirá que estos nuevos miembros del equipo se comuniquen con sus colegas en busca de ayuda.

Un monorepo simplifica las cosas. Dado que hay una única ubicación que contiene todo el código y la documentación, puede simplificar la configuración inicial.

Gestión de código centralizada

Tener un único repositorio brinda visibilidad de todo el código a todos los desarrolladores. Simplifica la gestión del código, ya que podemos usar un único rastreador de problemas para observar todos los problemas a lo largo del ciclo de vida de la aplicación.

Por ejemplo, estas características son valiosas cuando un problema abarca dos (o más) bibliotecas secundarias con el error existente en la biblioteca dependiente. Con varios repositorios, puede resultar difícil encontrar el fragmento de código donde ocurre el problema.

Además de esto, tendríamos que averiguar qué repositorio usar para crear el problema y luego invitar y etiquetar a miembros de otros equipos para ayudar a resolver el problema.

Sin embargo, con un monorepo, tanto la localización de problemas de código como la colaboración para solucionar problemas se vuelven más fáciles de lograr.

Refactorizaciones indoloras para toda la aplicación

Al crear una refactorización del código en toda la aplicación, se verán afectadas varias bibliotecas. Si los aloja a través de varios repositorios, administrar todas las diferentes solicitudes de extracción para mantenerlos sincronizados entre sí puede resultar un desafío.

Un monorepo facilita la realización de todas las modificaciones en todo el código de todas las bibliotecas y enviarlo en una única solicitud de extracción.

Más difícil de romper la funcionalidad adyacente

Con monorepo, podemos configurar todas las pruebas para que todas las bibliotecas se ejecuten siempre que se modifique una sola biblioteca. Como resultado, la probabilidad de realizar un cambio en algunas bibliotecas ha minimizado los efectos adversos en otras bibliotecas.

Los equipos comparten la cultura del desarrollo

Aunque no es imposible, con un enfoque de monorepo, se vuelve un desafío inspirar subculturas únicas entre diferentes equipos. Dado que compartirán el mismo repositorio, lo más probable es que compartan las mismas metodologías de programación y gestión y utilicen las mismas herramientas de desarrollo.

Problemas con el enfoque de Monorepo

Usar un solo repositorio para todo nuestro código tiene varios inconvenientes.

Ciclos de desarrollo más lentos

Cuando el código de una biblioteca contiene cambios importantes, que hacen que fallen las pruebas de las bibliotecas dependientes, el código también debe corregirse antes de fusionar los cambios.

Si estas bibliotecas dependen de otros equipos, que están ocupados trabajando en alguna otra tarea y no pueden (o no quieren) adaptar su código para evitar los cambios importantes y hacer que las pruebas pasen, el desarrollo de la nueva función puede estancarse.

Es más, el proyecto puede comenzar a avanzar solo a la velocidad del equipo más lento de la empresa. Este resultado podría frustrar a los miembros de los equipos más rápidos, creando las condiciones para que quieran dejar la empresa.

Además, una biblioteca también deberá ejecutar las pruebas para todas las demás bibliotecas. Cuantas más pruebas se ejecuten, más tiempo llevará ejecutarlas, lo que ralentizará la velocidad con la que podemos iterar en nuestro código.

Requiere la descarga de toda la base de código

Cuando el monorepo contiene todo el código de una empresa, puede ser enorme y contener gigabytes de datos. Para contribuir a cualquier biblioteca alojada dentro, cualquiera necesitaría una descarga de todo el repositorio.

Lidiar con una amplia base de código implica un mal uso del espacio en nuestros discos duros e interacciones más lentas con él. Por ejemplo, acciones cotidianas como ejecutar git status o buscar en el código base con una expresión regular puede llevar muchos segundos o incluso minutos más de lo que lo harían con varios repositorios.

Las bibliotecas no modificadas pueden tener nuevas versiones

Cuando etiquetamos el monorepo, a todo el código dentro se le asigna la nueva etiqueta. Si esta acción desencadena una nueva versión, todas las bibliotecas alojadas en el repositorio se publicarán nuevamente con el número de versión de la etiqueta, aunque muchas de esas bibliotecas pueden no haber tenido ningún cambio.

Bifurcar es más difícil

Los proyectos de código abierto deben facilitar al máximo la participación de los contribuyentes. Con varios repositorios, los contribuyentes pueden dirigirse directamente al repositorio específico del proyecto al que desean contribuir. Sin embargo, con un monorepo que alberga varios proyectos, los contribuyentes primero deben navegar hacia el proyecto correcto y deberán comprender cómo su contribución puede afectar a todos los demás proyectos.

¿Qué es Multi-Repo?

El enfoque de repositorios múltiples utiliza varios repositorios para alojar las múltiples bibliotecas o servicios de un proyecto desarrollado por una empresa. En su forma más extrema, albergará cada conjunto mínimo de código reutilizable o funcionalidad independiente (como un microservicio) en su repositorio.

Beneficios de Multi-Repo

Alojar cada biblioteca de forma independiente de todas las demás proporciona una gran cantidad de beneficios.

Control de versiones de bibliotecas independientes

Al etiquetar un repositorio, a todo su código base se le asigna la etiqueta «nueva». Dado que solo el código para una biblioteca específica está en el repositorio, la biblioteca se puede etiquetar y versionar independientemente de todas las demás bibliotecas alojadas en otro lugar.

Tener una versión independiente para cada biblioteca ayuda a definir el árbol de dependencias de la aplicación, lo que nos permite configurar qué versión de cada biblioteca usar.

Comunicados de servicio independientes

Dado que el repositorio solo contiene el código de algún servicio y nada más, puede tener su propio ciclo de implementación, independientemente de cualquier progreso realizado en las aplicaciones que acceden a él.

El servicio puede utilizar un ciclo de lanzamiento rápido, como la entrega continua (donde se implementa nuevo código después de pasar todas las pruebas). Algunas bibliotecas que acceden al servicio pueden utilizar un ciclo de publicación más lento, como las que solo producen una nueva versión una vez a la semana.

Ayuda a definir el control de acceso en toda la organización

Solo los miembros del equipo involucrados en el desarrollo de una biblioteca deben agregarse al repositorio correspondiente y descargar su código. Como resultado, existe una estrategia de control de acceso implícita para cada capa de la aplicación. A los involucrados con la biblioteca se les otorgarán derechos de edición, y es posible que todos los demás no tengan acceso al repositorio. O se les puede otorgar derechos de lectura pero no de edición.

Permite que los equipos trabajen de forma autónoma

Los miembros del equipo pueden diseñar la arquitectura de la biblioteca e implementar su código trabajando de forma aislada de todos los demás equipos. Pueden tomar decisiones basadas en lo que hace la biblioteca en el contexto general sin verse afectados por los requisitos específicos de algún equipo o aplicación externos.

Problemas con el enfoque de repositorio múltiple

El uso de varios repositorios puede dar lugar a varios cuestiones.

Las bibliotecas deben volver a sincronizarse constantemente

Cuando se lanza una nueva versión de una biblioteca que contiene cambios importantes, las bibliotecas que dependen de esta biblioteca deberán adaptarse para comenzar a usar la última versión. Si el ciclo de lanzamiento de la biblioteca es más rápido que el de sus bibliotecas dependientes, podrían perder la sincronización rápidamente entre sí.

Los equipos deberán ponerse al día constantemente para utilizar las últimas versiones de otros equipos. Dado que los diferentes equipos tienen diferentes prioridades, esto a veces puede resultar difícil de lograr.

En consecuencia, un equipo que no pueda ponerse al día puede terminar apegándose a la versión desactualizada de la biblioteca dependiente. Este resultado tendrá implicaciones en la aplicación (en términos de seguridad, velocidad y otras consideraciones), y es posible que la brecha en el desarrollo entre las bibliotecas solo se amplíe.

Equipos de fragmentos de mayo

Cuando los diferentes equipos no necesitan interactuar, pueden trabajar en sus propios silos. A largo plazo, esto podría dar lugar a que los equipos produzcan sus subculturas dentro de la empresa, por ejemplo, empleando diferentes metodologías de programación o gestión o utilizando diferentes conjuntos de herramientas de desarrollo.

Si algún miembro del equipo eventualmente necesita trabajar en un equipo diferente, puede sufrir un pequeño choque cultural y aprender una nueva forma de hacer su trabajo.

Monorepo vs Multi-Repo: diferencias principales

En última instancia, ambos enfoques tratan con el mismo objetivo: administrar el código base. Por lo tanto, ambos deben resolver los mismos desafíos, incluida la administración de versiones, el fomento de la colaboración entre los miembros del equipo, el manejo de problemas, la ejecución de pruebas y otros.

Su principal diferencia se refiere al tiempo que tienen los miembros del equipo para tomar decisiones: ya sea por adelantado para monorepo o en el futuro para varios repositorios.

Analicemos esta idea con más detalle.

Debido a que todas las bibliotecas tienen versiones independientes en el repositorio múltiple, un equipo que lanza una biblioteca con cambios importantes puede hacerlo de manera segura al asignar un nuevo número de versión principal a la última versión. Otros grupos pueden hacer que sus bibliotecas dependientes se adhieran a la versión anterior y cambien a la nueva una vez que se haya adaptado su código.

Este enfoque deja la decisión de cuándo adaptar todas las demás bibliotecas a cada equipo responsable, que puede hacerlo en cualquier momento. Si lo hacen demasiado tarde y se lanzan nuevas versiones de bibliotecas, cerrar la brecha entre las bibliotecas será cada vez más difícil.

En consecuencia, si bien un equipo puede iterar rápidamente y con frecuencia en su código, otros equipos pueden resultar incapaces de ponerse al día y, en última instancia, producir bibliotecas que divergen.

Por otro lado, en un entorno monorepo, no podemos lanzar una nueva versión de una biblioteca que rompa otra biblioteca ya que sus pruebas fallarán. En este caso, el primer equipo debe comunicarse con el segundo equipo para incorporar los cambios.

Este enfoque obliga a los equipos a adaptar todas las bibliotecas por completo siempre que deba ocurrir un cambio para una sola biblioteca. Todos los equipos se ven obligados a hablar entre ellos y llegar juntos a una solución.

Como resultado, el primer equipo no podrá iterar tan rápido como quisiera, pero el código en diferentes bibliotecas en ningún momento comenzará a divergir.

En resumen, el enfoque de repositorios múltiples puede ayudar a crear una cultura de «moverse rápido y romper cosas» entre los equipos, donde los equipos independientes ágiles pueden producir su salida a su velocidad. En cambio, el enfoque de monorepo favorece una cultura de conciencia y cuidado, donde los equipos no deben quedarse atrás para lidiar con un problema por sí mismos.

Enfoque híbrido Poly-As-Mono

Si no podemos decidir si usar los enfoques de múltiples repositorios o monorepo, también existe el enfoque intermedio: usar múltiples repositorios y emplear alguna herramienta para mantenerlos sincronizados, haciéndolo parecerse a un monorepo pero con más flexibilidad.

Meta es una de esas herramientas. Organiza varios repositorios en subdirectorios y proporciona una interfaz de línea de comandos que ejecuta el mismo comando en todos ellos simultáneamente.

Un meta-repositorio contiene la información sobre qué repositorios componen un proyecto. La clonación de este repositorio a través de metadatos clonará de forma recursiva todos los repositorios necesarios, lo que facilitará que los nuevos miembros del equipo comiencen a trabajar en sus proyectos de inmediato.

Para clonar un meta-repositorio y todos sus repositorios múltiples definidos, debemos ejecutar lo siguiente:

meta git clone [meta repo url]

Meta ejecutará un git clone para cada repositorio y colóquelo en una subcarpeta:

A partir de entonces, ejecutando el meta exec comando ejecutará el comando en cada subcarpeta. Por ejemplo, ejecutando git checkout master en cada repositorio se hace así:

meta exec "git checkout master"

Enfoque híbrido Mono-As-Poly

Otro enfoque es administrar el código a través de un monorepo para el desarrollo, pero copiando el código de cada biblioteca en su repositorio independiente para su implementación.

Esta estrategia prevalece dentro del ecosistema PHP porque Packagist (el repositorio principal de Composer) requiere una URL de repositorio público para publicar un paquete, y no es posible indicar que el paquete está ubicado dentro de un subdirectorio del repositorio.

Dada la limitación de Packagist, los proyectos PHP aún pueden usar un monorepo para el desarrollo, pero deben usar el enfoque de repositorios múltiples para la implementación.

Para lograr esta conversión, podemos ejecutar un script con git subtree split O use una de las herramientas disponibles que realizan la misma lógica:

Quién usa Monorepo vs Multi-Repo

Varias grandes empresas de tecnología favorecen el enfoque de monorepo, mientras que otras han decidido utilizar el método de repositorios múltiples.

Google, Facebook, Gorjeo, y Uber han respaldado públicamente el enfoque de monorepo. Microsoft ejecuta el monorepo Git más grande del planeta para alojar el código fuente del sistema operativo Windows.

En el lado opuesto, Netflix, Amazon y Lyft son empresas famosas que utilizan el enfoque de repositorios múltiples.

En el lado híbrido poli-como-mono, Android actualiza múltiples repositorios, que se administran como un monorepo.

En el lado híbrido mono-como-poli, Symfony mantiene el código de todos sus componentes en un monorepo. Lo dividieron en repositorios independientes para su implementación (como symfony/dependency-injection y symfony/event-dispatcher.)

Ejemplos de Monorepo y Multi-Repo

La cuenta de WordPress en GitHub aloja ejemplos de los enfoques monorepo y multi-repositorio.

Gutenberg, el editor de bloques de WordPress, está compuesto por varias docenas de paquetes de JavaScript. Todos estos paquetes están alojados en el WordPress/gutenberg monorepo y administrado a través de Lerna para ayudar a publicarlos en el repositorio npm.

Openverse, el motor de búsqueda de medios con licencia abierta, aloja sus partes principales en repositorios independientes: Front-end, Catalog y API.

Monorepo vs Multi-Repo: ¿Cómo elegir?

Como ocurre con muchos problemas de desarrollo, no existe una respuesta predefinida sobre qué enfoque debe utilizar. Diferentes empresas y proyectos se beneficiarán de una estrategia u otra en función de sus condiciones únicas, tales como:

• ¿Qué tan grande es el código base? ¿Contiene gigabytes de datos?
• ¿Cuántas personas trabajarán en el código base? ¿Es alrededor de 10, 100 o 1000?
• ¿Cuántos paquetes habrá? ¿Es alrededor de 10, 100 o 1000?
• ¿En cuántos paquetes debe trabajar el equipo en un momento dado?
• ¿Qué tan bien acoplados están los paquetes?
• ¿Están involucrados diferentes lenguajes de programación? ¿Requieren la instalación de un software en particular o un hardware especial para su ejecución?
• ¿Cuántas herramientas de implementación se requieren y qué tan complejas son de configurar?
• ¿Cuál es la cultura en la empresa? ¿Se anima a los equipos a colaborar?
• ¿Qué herramientas y tecnologías saben utilizar los equipos?

¿Qué enfoque debería tomar para su base de código? 🤔 Obtenga más información aquí 👇Haz clic para tuitear

Resumen

Hay dos estrategias principales para alojar y administrar código: monorepo vs multi-repo. El enfoque de monorepo implica almacenar el código para diferentes bibliotecas o proyectos, e incluso todo el código de una empresa, en un solo repositorio. Y el sistema de repositorios múltiples divide el código en unidades, como bibliotecas o servicios, y mantiene su código alojado en repositorios independientes.

El enfoque a utilizar depende de una multitud de condiciones. Ambas estrategias tienen varias ventajas y desventajas, y las hemos cubierto todas en detalle en este artículo.

¿Te queda alguna duda sobre monorepos o multi-repositorios? ¡Infórmenos en la sección para comentarios!