No tienes acceso a esta clase

¬°Contin√ļa aprendiendo! √önete y comienza a potenciar tu carrera

Aprende todo un fin de semana sin pagar una suscripci√≥n ūüĒ•

Aprende todo un fin de semana sin pagar una suscripci√≥n ūüĒ•

Regístrate

Comienza en:

1D
0H
1M
7S

Monorepositorios vs. Multirepositorios

8/15
Recursos

Aportes 2

Preguntas 2

Ordenar por:

¬ŅQuieres ver m√°s aportes, preguntas y respuestas de la comunidad?

o inicia sesión.

Multirepositorios

En esta estrategia cada componente o parte de un proyecto con entidad propia se aloja en un repositorio diferente. Por ejemplo, si tenemos un proyecto que tiene un frontend y un backend, cada uno de ellos se alojaría en un repositorio diferente. Incluso, dentro del frontend podriamos separar en diferentes repositorios el design system (componentes visuales), el tema, etc.
Ventajas

  • Tener un versionado independiente
  • Despliegues independientes
  • Ayuda a definir el control de acceso
  • Las ramas de los repositorios son m√°s peque√Īas

Desventajas

  • Es dif√≠cil de orquestar las nuevas versiones y sincronizar entre los repositorios
  • Para crear una nueva feature hay que crear diferentes pull request en los diferentes repositorios. Esto cuesta mucho tiempo
  • Fragmentaci√≥n de equipos y ciclos de conocimiento
  • El ciclo de feedback es lento
  • Mucho trabajo manual

Monorepositorios

Son repositorios que contienen todo el código de una aplicación. Este repositorio tendría paquetes separados, y cada paquete tiene una entidad propia.
El monorepositorio debe tener (como todo proyecto) una buena estructura de carpetas.
Ventajas

  • Cuando una persona nueva entra al equipo solo tiene que clonar un solo repositorio y ya tiene el proyecto.
  • La refactorizaci√≥n de c√≥digo es m√°s f√°cil.
  • Crear una feature en un solo pull request
  • Todo los equipos puede estar trabajando en el mismo c√≥digo

Desventajas

  • Ciclos pueden ser un poco m√°s lentos
  • Se requiere de la descarga de todo el c√≥digo base para trabajar

Lo mejor en un monorepositorio es usar el mismo stack tecnológico, mismo lenguaje de programación, mismo framework, las mismas reglas de linter.

en laravel por ahora solo he trabajado con monorepositorios pero viendo esta clase creo que lo pensaría para futuros proyectos