Foto de Andres Ayrton
La elección entre utilizar un monorepo o un multirepo en Git puede marcar la diferencia entre el éxito y el estancamiento de un proyecto.
Este artículo es por qué recientemente ayudé a un equipo a comenzar su viaje por Git y a una serie de discusiones con un grupo de amigos. A mis amigos les remití a este artículo de Google: «Why Google Stores Billions of Lines of Code in a Single Repository«. Aquí apliqué mi frase, se que la repito mucho: en la vida no es todo blanco o negro, es una gama infinita de grises.
Lo primero que quiero que entiendan es que un monorepo no se debe asociar con monolito y que multirepo, por extensión, tampoco debe asociarse a microservicios. Es decir, un monolito puede ser administrado en un monorepo. Pero también se puede dividir un monolito en varios repositorios. De manera similar, se puede usar un monorepo con microservicios en lugar de un monolito.
Voy a hablar desde el lado de .NET y algunas de las cosas que me han pasado trabajando con Node.js en este artículo no tienen sentido, con Node.js un monorepo y multirepo lleva asociado más decisiones y forma de trabajar que con .NET, en .NET es todo más sencillo.
¿qué son los monorepos y los multi-repos?
Cuando se trata de control de versiones y gestión de proyectos, hay dos enfoques principales que los desarrolladores pueden utilizar: los monorepos y los multi-repos:
- Los monorepos, abreviatura de repositorios monolíticos, se refieren a una estrategia de control de versiones en la que todos los proyectos dentro de una organización se almacenan en un solo repositorio.
- Los multi-repos, por otro lado, implican el uso de varios repositorios para almacenar y gestionar proyectos. En este artículo, compararemos los dos enfoques y examinaremos los pros y los contras de cada uno.
Comparación
| Ventajas de los Monorepos en .NET | Inconvenientes de los Monorepos en .NET |
|---|---|
| Gestión simplificada de versiones y seguimiento | Mayor complejidad en la configuración inicial |
| Mejora de la colaboración entre equipos y desarrolladores | Dificultad para manejar monorepos grandes |
| Compartir código de manera más eficiente | Puede no ser adecuado para proyectos con una fuerte separación de responsabilidades |
| Pruebas e integración más eficientes | Riesgo de crecimiento inmanejable a medida que el repositorio crece en tamaño |
| Mayor visibilidad y comprensión del código y las relaciones entre proyectos |
| Ventajas de los Multi-repos | Inconvenientes de los Multi-repos |
|---|---|
| Mayor simplicidad en la configuración y gestión | Mayor complejidad para mantener y gestionar múltiples repositorios |
| Más adecuado para proyectos con una fuerte separación de responsabilidades | Dificultad para compartir código de manera eficiente entre proyectos |
| Flexibilidad para equipos grandes o proyectos con subproyectos distintos | Dificultad para realizar un seguimiento de cómo los cambios en un repositorio afectan a otros |
| Menor riesgo de crecimiento inmanejable a medida que los repositorios aumentan en número | Menor visibilidad y comprensión del panorama general del proyecto |
| Mayor dificultad para realizar pruebas e integración en varios repositorios |
¿Qué es recomendable para Microservicios?
En mi caso para microservicios (no perdamos que estamos en .NET), esta es mi posición por la que me gusta escoger multi-repo y usar NuGets:
-
Separación de responsabilidades: Los microservicios se centran en la idea de tener servicios individuales, independientes y con su propio contexto. Al utilizar un enfoque de Multi-repo, cada microservicio puede tener su propio repositorio, lo que facilita la separación y el enfoque en la responsabilidad específica de cada servicio.
-
Gestión de versiones de NuGet: Con múltiples repositorios, es más fácil gestionar las dependencias y las versiones de NuGet para cada microservicio de manera independiente. Cada microservicio puede utilizar las versiones específicas de NuGet que necesita sin interferir con otros microservicios.
-
Flexibilidad y escalabilidad: Los microservicios suelen ser pequeños y ágiles, lo que permite la escalabilidad y el despliegue independiente de cada servicio. Al utilizar un enfoque de Multi-repo, es más sencillo gestionar y desplegar cada microservicio de manera independiente, lo que facilita la flexibilidad y la evolución individual de cada servicio.
-
Aislamiento de errores y pruebas: Con repositorios separados, es más fácil aislar errores y realizar pruebas específicas en cada microservicio. Esto permite una depuración y una mejora más eficientes, ya que cada servicio puede ser tratado de manera aislada.
-
Mejor control de versiones: Cada microservicio puede tener su propio control de versiones, lo que facilita el seguimiento de los cambios y las actualizaciones específicas de cada servicio.
Y aquí una de las cuestiones o justificaciones que hubo en el debate
Así podrás tomar una decisión fundamentada cuando uses una u otra aproximación aplicada a microservicios. Algunos escenarios en los que un Monorepo podría ser beneficioso:
-
Compartir y gestionar código compartido: Si tus microservicios comparten una cantidad significativa de código, tener un Monorepo facilita la gestión y el mantenimiento de ese código compartido. Puedes tener un directorio dedicado para las bibliotecas compartidas (NuGets) dentro del Monorepo, lo que permite un control más centralizado y una mayor reutilización de código.
-
Simplificación de la gestión de versiones: Con un Monorepo, puedes asegurarte de que todos los microservicios utilicen las mismas versiones de NuGet. Esto puede simplificar la gestión de versiones y evitar posibles conflictos entre los servicios que dependen de diferentes versiones de la misma biblioteca. Aquí tengo mi duda, pero la pongo ya que no hubo consenso. Como es mi blog, os digo que yo pienso que esto no ocurre así, el sitio donde tenemos los NuGet es para todos los microservicios, y si tienes la constumbre de actualizar y revisar las versiones nuevas de NuGet esto no aporta nada, lo único que te aporta es que puedes ver el historial en Git, pero si son muchas personas el cambio tambien se puede perder en la historia.
-
Facilitar las pruebas y la integración: Al tener todos los microservicios en un solo repositorio, es más fácil realizar pruebas de integración que involucren varios servicios al mismo tiempo. Además, las pruebas y los ajustes de compatibilidad entre los servicios pueden llevarse a cabo de manera más eficiente. En este caso, depende mucho si estas en serverless o estas en contenedores. En Serverless es más complicado ya que ¿cómo levantas la otra Function?, en Docker usas un docker-compse y a correr.
-
Mayor visibilidad y colaboración: Al contar con todos los microservicios en un Monorepo, los equipos de desarrollo pueden tener una visión general más clara de todo el sistema. Esto facilita la colaboración, la comprensión global del proyecto y la resolución de problemas que abarquen varios microservicios. Y aquí depende mucho del tipo de equipo que tengas.
Conclusión
En última instancia, la elección entre un enfoque de Monorepo o Multi-repo depende tanto del proyecto en sí como del equipo humano involucrado, ya que cada enfoque tiene sus ventajas y desventajas. Es fundamental evaluar cuidadosamente las necesidades del proyecto, la estructura del equipo, la naturaleza del código y las preferencias individuales antes de tomar una decisión informada sobre cuál es el enfoque más adecuado para lograr una gestión eficiente, una colaboración efectiva y un desarrollo exitos.
La infinita escala comática de grises, no os he descubierto nada nuevo. Pero si que con argumentos puedes afianzar tu elección y si alguien pone en duda tu elección que puedas defenderla.
