Mono-repositorio y repositorio múltiple son dos estrategias principales para alojar y administrar código a través de Git. Discutimos en detalle las estrategias y sus pros y contras.
Introducción
La mayoría de los proyectos modernos se gestionan y alojan en Git. Git se ha convertido en la plataforma estándar para la gestión de código fuente distribuido, control de versionesy colaboración desde cualquier parte del mundo. Git es rápido y eficiente. Hay dos enfoques principales para alojar y administrar su código Git:
- Mono-repositorio
- Repositorio múltiple
Antes de profundizar en estos enfoques, comprendamos cómo funciona el repositorio.
¿Qué son los repos?
Un repositorio (Repo) contiene todas las carpetas y archivos de su proyecto. También contiene información sobre usuarios, personas y computadoras.
Los datos del repositorio están controlados por versiones. Un repositorio puede ser propiedad de una persona o de un grupo de miembros del equipo.
Git es un repositorio. Puede ser público, privado o interno. GitHub es un servicio de alojamiento del repositorio Git y tiene una interfaz de usuario.
Git proporciona funciones de control de versiones y uso compartido de código, sin embargo, lo que hace a Git diferente es que si los desarrolladores quieren hacer algunos cambios en sus archivos, pueden copiar todo el repositorio en su sistema local. Por lo tanto, incluso si un desarrollador no tiene acceso de escritura a un proyecto en particular, puede copiar el contenido localmente y modificarlo (llamado bifurcación).
Además, si el desarrollador desea compartir los cambios realizados localmente, puede enviar una "solicitud de extracción" al propietario del proyecto.
Un proyecto puede tener un solo servicio. Si tu proyecto tiene múltiples workflows, puede crear varios servicios para cada flujo de trabajo. La mayoría de los desarrolladores prefieren dividir proyectos más grandes en servicios independientes más pequeños, con una o más funciones. Cada servicio puede resolver varios problemas comerciales. Con la popularidad de frameworks sin servidor, los usuarios pueden acceder a funciones como servicios.
Una vez que cree estas funciones como servicios y las implemente, el siguiente paso es estructurarlas y controlarlas de la versión; puede tener todos sus servicios en un repositorio (mono-repositorio), o tener un repositorio separado para cada servicio que tenga ( multi-repositorio)!
¿Qué es un Mono-repositorio?
En un enfoque de repositorio único, puede mantener todos sus servicios en un único repositorio (mono). Aún puede implementar y administrar cada servicio de forma independiente. Los servicios pueden compartir códigos y bibliotecas comunes.
Empresas como Facebook, Google y Dropbox utilizan mono-repositorio.
Ventajas de Mono-repo
El enfoque de mono-repositorio tiene muchas ventajas:
- Un solo lugar para almacenar todo el código del proyecto, y todos los miembros del equipo pueden acceder a él
- Fácil de reutilizar y compartir código, colaborar con el equipo
- Fácil de comprender el impacto de su cambio en todo el proyecto
- La mejor opción para la refactorización de código y grandes cambios en el código
- Los miembros del equipo pueden obtener una vista general de todo el proyecto
- Dependencias fáciles de administrar
Desventajas de Mono-repo
Por supuesto, el mono-repositorio tiene algunas desventajas, la principal es el rendimiento. Si su proyecto crece y se agregan más archivos cada dos días, las operaciones de extracción, extracción y otras pueden volverse lentas y las búsquedas de archivos pueden demorar más.
Además, si contrata a muchos contratistas independientes para su proyecto, darles acceso a todo el código base puede no ser tan seguro.
Además, es difícil implementar implementaciones continuas (CD), porque muchas personas pueden registrar sus cambios y su sistema de integración continua (CI) puede tener que realizar varias reconstrucciones.
Las grandes empresas que utilizan repositorios únicos tienen herramientas personalizadas para manejar los problemas de ampliación. Por ejemplo, Facebook usa un sistema de archivos personalizado y un control de fuente.
¿Qué es un repositorio múltiple?
En un enfoque de repositorios múltiples, existen varios repositorios que albergan varias bibliotecas y servicios de un proyecto. Si un servicio cambia, los desarrolladores deben reconstruir solo ese servicio y no todo el proyecto. Las personas y los equipos pueden trabajar en sus servicios específicos y solo obtienen acceso a los servicios requeridos.
Compañías como Netflix y Amazon usan repositorios múltiples.
Ventajas de Multi-repo
La cantidad de empresas que adoptan repositorios múltiples es mucho mayor que las que optan por un repositorio único, debido a las siguientes razones:
- Cada servicio y biblioteca tiene su propio control de versiones.
- Las comprobaciones y extracciones de código son pequeñas e independientes, por lo que no hay problemas de rendimiento incluso si el tamaño del proyecto crece
- Los equipos pueden trabajar de forma independiente y no necesitan tener acceso a todo el código base
- Desarrollo y flexibilidad más rápidos
- Cada servicio puede lanzarse por separado y tener su propio ciclo de implementación, lo que facilita la implementación de CI y CD
- Mejor control de acceso: no es necesario que todos los equipos tengan acceso completo a todas las bibliotecas, pero pueden obtener acceso de lectura si lo necesitan
Desventajas de Multi-repo
- Las dependencias y bibliotecas utilizadas en los servicios y proyectos deben sincronizarse periódicamente para obtener la última versión.
- Fomenta una cultura aislada en algún momento, lo que genera código duplicado y equipos individuales que intentan resolver el mismo problema.
- Cada equipo puede seguir un conjunto diferente de mejores prácticas para su código, lo que genera dificultades para seguir las mejores prácticas comunes.
Diferencias entre Mono y Multi Repo
Recapitulemos las diferencias entre mono-repositorio y multi-repositorio:
| Mono-repositorio | Repositorio múltiple |
| Todo el código de todos los proyectos de una organización reside en un repositorio central | Cada servicio y proyecto tiene un repositorio separado |
| Los equipos pueden colaborar y trabajar juntos; pueden ver los cambios de los demás | Los equipos pueden trabajar de forma autónoma; los cambios individuales no afectan los cambios de otros equipos o proyectos |
| Cada persona tiene acceso a toda la estructura del proyecto. | Los administradores pueden limitar el control de acceso al proyecto o servicio al que el desarrollador necesita acceder |
| Pueden ocurrir problemas de ampliación si el tamaño del proyecto sigue creciendo | Buen rendimiento, debido al código limitado y a las unidades de servicio más pequeñas. |
| Difícil de implementar Despliegue Continuo (CD) e Integración Continua (CI) | Los desarrolladores pueden lograr fácilmente CD y CI porque pueden crear servicios de forma independiente |
| Los desarrolladores pueden compartir fácilmente bibliotecas, API y otro código común a medida que se actualizan en el repositorio central. | Cualquier cambio en las bibliotecas y otro código común debe sincronizarse periódicamente para evitar problemas más adelante. |
Conclusión
Tanto el repositorio único como el repositorio múltiple son igualmente populares y cuál es mejor depende del tamaño de su proyecto, los requisitos del proyecto y el nivel de control de versiones y acceso que necesita.
El repositorio único favorece la coherencia, mientras que el repositorio múltiple se centra en el desacoplamiento. Mientras que en un repositorio único, todo el equipo puede ver los cambios realizados por una persona, el repositorio múltiple crea un repositorio separado para cada equipo, que tiene acceso solo a los servicios requeridos. Si desea utilizar una combinación de repositorio único y repositorio múltiple para sus proyectos, puede optar por meta, una herramienta para administrar múltiples proyectos y bibliotecas.
También podría interesarle Recursos gratuitos para aprender Git.
