Pros y contras de la estrategia de repositorio de código

Hay dos tácticas primordiales para alojar y administrar código por medio de Git: repositorio mono y repositorio múltiple. Ambos metodos tienen sus ventajas y desventajas.

Podemos usar cualquier método con cualquier código base en cualquier idioma. Puede usar cualquiera de estas estrategias en proyectos que integren una pequeña proporción de bibliotecas y miles de bibliotecas. Incluso si existen algunos integrantes del equipo comprometidos, cientos y cientos de personas, o si quiere alojar un código abierto o privado, puede elegir Monorepo o Multirepo en función de múltiples factores.

¿Cuáles son las virtudes y desventajas de cada procedimiento? ¿Cuándo deberíamos emplear uno de ellos? ¡Vamos a saber!

¿Qué es una recompra?

Repo (abreviatura de repositorio) es el registro de todos y cada uno de los cambios y archivos en un emprendimiento a fin de que los desarrolladores puedan "regentar la versión" de los recursos del proyecto a lo largo de la etapa de desarrollo.

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

Hay dos estrategias principales para alojar y regentar nuestra plantilla de código a través de Git: el procedimiento monorepo y el método monirepo. 🚀 Lea todo en esta guía ⬇️Realice click para twittear

¿Qué es un repositorio mono?

El procedimiento Monorepo emplea un único repositorio para alojar todo el código de varias bibliotecas o servicios que conforman un emprendimiento empresarial. En casos extremos, todo el código base de la compañía, codificado en diferentes proyectos y en diferentes lenguajes, se aloja en un solo archivo.

Las ventajas del monorepo

Alojar toda la base de código en un solo repositorio tiene los próximos beneficios.

Barreras de entrada más bajas

Cuando los nuevos usados comienzan a trabajar para una empresa, tienen que descargar el código e instalar las herramientas primordiales antes de comenzar a trabajar. Por ejemplo, suponga que un proyecto está disperso en varios archivos, cada uno con normas de instalación y las herramientas necesarias. En un caso así, la configuración inicial es complicada y la documentación tiende a estar incompleta, por lo que estos nuevos miembros del equipo tienen que buscar la asistencia de sus colegas.

monorepo facilita el problema. Debido a que hay un espacio que contiene todos los códigos y documentos, puede hacer más simple la instalación inicial.

Administración de código con una central

El archivo permite a todos los programadores ver el código terminado. Facilita la administración del código pues tenemos la posibilidad de emplear un único rastreador de inconvenientes para rastrear todos y cada uno de los inconvenientes en todo el ciclo vital de la aplicación.

Estas características son útiles, por ejemplo, cuando el inconveniente es con dos (o mucho más) sub-bibliotecas y se producen errores en bibliotecas dependientes. Con varios repositorios, puede ser bien difícil encontrar el segmento de código donde sucede el inconveniente.

Lo más esencial es que determinamos qué archivo se empleará para hacer el inconveniente y luego invitamos a integrantes de otros equipos para que ayuden a resolver el inconveniente.

No obstante, Monorepo provoca que sea mucho más fácil conseguir y arreglar problemas de código juntos.

Reestructuración dinámica del alcance

Si se cambia el alcance del código, afectará a múltiples bibliotecas. Cuando los alberga en varios repositorios, dirigir todas y cada una las distintas solicitudes para sincronizarlos puede ser un desafío.

Monorepo puede realizar de forma fácil todos y cada uno de los cambios en todos los códigos de la biblioteca y enviarlos con solo una petición.

Es mucho más bien difícil interrumpir las actividades de los vecinos.

Con Monorepo, tenemos la posibilidad de modificar todas las pruebas a fin de que se ejecuten para todas y cada una de las bibliotecas al cambiar una biblioteca. Por consiguiente, la capacidad de efectuar cambios en varias bibliotecas ha minimizado los efectos adversos en otras bibliotecas.

Distribuyendo la cultura del avance en grupo

Más allá de que esto no es imposible, el desafío va a ser utilizar el procedimiento monorepo para inspirar subculturas únicas entre diferentes grupos. Ya que tienen el mismo fichero, probablemente empleen exactamente los mismos métodos de programación y administración y herramientas de desarrollo.

Inconveniente con el método Monorepo

Hay varias desventajas de usar un solo repositorio para todo nuestro código.

Ciclo de desarrollo mucho más lento

Si el código de la biblioteca contiene cambios destructivos que hacen que falle una prueba de la biblioteca ligado, el código también debe corregirse antes de fusionar los cambios.

En el momento en que estas bibliotecas dependen de otros equipos que están ocupados con otras tareas y no tienen la posibilidad de (o no quieren) cambiar su código para eludir que los cambios rompan y pasen las pruebas, el desarrollo de novedosas funciones puede detenerse.

Más importante aún, probablemente el proyecto avance solo con el equipo mucho más retardado de la compañía. Este resultado puede frustrar a los miembros más veloces del equipo y hacer las condiciones para su deseo de dejar la compañía.

Además, la biblioteca debe realizar pruebas en todas las demás bibliotecas. Cuantas más pruebas tengamos que realizar, más tiempo va a llevar, lo que disminuye la agilidad a la que iteramos el código.

Tienes que bajar el código base terminado

Si una mochila mono tiene dentro todo el código de la compañía, puede ser realmente grande. Todos tienen que poder entrar a la biblioteca que sostiene y todos tienen que bajar el archivo terminado.

Conducir una gran cantidad de código significa hacer un mal empleo del espacio del disco duro y una interacción mucho más lenta con él; por poner un ejemplo, ocupaciones cotidianas como la ejecución git status O, el uso de expresiones regulares para buscar una base de código puede llevar varios segundos o aun minutos más que la utilización de múltiples repositorios.

Una biblioteca sin modificar puede ser una nueva versión

Cuando etiquetamos a Monorepo, todo el código que contenía recibió una exclusiva etiqueta. En el momento en que esta función lanza una exclusiva versión, todas y cada una de las bibliotecas alojadas en el archivo con el número de versión en la etiqueta se volverán a divulgar, si bien posiblemente muchas de ellas no tengan ningún cambio.

Las horquillas son mucho más pesadas

Los proyectos de código abierto tienen que hacer que la participación de los autores sea lo mucho más simple viable. Múltiples ficheros permiten a los participantes acceder de forma directa al archivo específico del emprendimiento en el que quieren formar parte. Sin embargo, en el momento en que Monorepo organiza diferentes proyectos, los participantes tienen que primero presentarles el proyecto correcto y comprender cómo sus aportes pueden perjudicar a todos los demás proyectos.

¿Qué es una recompra múltiple?

El enfoque de múltiples repositorios utiliza múltiples repositorios para alojar múltiples repositorios o servicios para proyectos desarrollados por la empresa. En el caso radical, alberga en su fichero cada pequeño código reutilizable o función independiente (como microservicios).

Provecho de las recompras múltiples

Independientemente del alojamiento de cada biblioteca, todas las demás bibliotecas tienen varios provecho.

Control de versión de biblioteca independiente

En el momento en que se marca un archivo, todo su código base se marca como "nuevo". Debido a que el archivo tiene dentro solo el código para una biblioteca específica, la biblioteca se puede etiquetar y versionar independientemente de otras bibliotecas alojadas en otro rincón.

Cada biblioteca tiene una versión separada para modificar el árbol de dependencia de la aplicación para que tengamos la posibilidad modificar cada versión de la biblioteca para usar.

Versión de servicio independiente

Debido a que el archivo tiene dentro solo el código para ciertos servicios y solamente, tiene la posibilidad de tener su ciclo de producción con independencia del avance de las aplicaciones que lo usan.

El servicio puede usar ciclos de bloqueo rápido, como Distribución continua (entrando un nuevo código tras todas y cada una de las pruebas). Ciertas bibliotecas que usan el servicio pueden utilizar un período de lanzamiento mucho más retardado, como las que lanzan nuevas versiones solo una vez por semana.

Ayude a sostener el ingreso a toda la organización que defina

Sencillamente añada los miembros del equipo involucrados en el avance de la biblioteca al fichero apropiado y descargue su código. Por lo tanto, cada escenario de app tiene un plan de control de ingreso implícita. La gente que se unen a la biblioteca reciben derechos de edición y posiblemente no todos los demás puedan entrar a la biblioteca. O se les dan privilegios de lectura pero no privilegios de edición.

Deje que los equipos trabajen de forma independiente

Los miembros del equipo tienen la posibilidad de diseñar la arquitectura de la biblioteca e llevar a cabo su código con independencia de otros grupos. Puede tomar resoluciones basadas en el accionar de la biblioteca en un contexto general sin verse afectado por las pretensiones concretas de un equipo o aplicación externos.

Problema con múltiples métodos de recompra

El uso de múltiples archivos puede causar varios inconvenientes.

La biblioteca debe estar todo el tiempo sincronizada

Cuando se lanza una nueva versión de una biblioteca y tiene dentro cambios esenciales, las bibliotecas que dependen de la biblioteca tienen que configurarse para emplear la última versión. Si el ciclo de publicación de una biblioteca es más rápido que el período de publicación de sus bibliotecas dependientes, posiblemente próximamente se sincronicen.

Los equipos deben mantener el control para poder aprovechar la última versión de otros equipos. Debido a que los distintos equipos tienen diferentes prioridades, esto a veces puede ser bien difícil.

Como resultado, los equipos que no quedan atrapados pueden acabar con versiones desactualizadas de bibliotecas dependientes. Este resultado tiene implicaciones en la aplicación (en concepto de seguridad, agilidad y otras caracteristicas), y la brecha de avance entre bibliotecas solo puede aumentar.

Puede romper un equipo

En el momento en que los distintos grupos no deben interaccionar, pueden trabajar en sus silos. En un largo plazo, esto puede llevar al equipo a crear su subcultura en la empresa, por ejemplo, adoptando distintas métodos de programación o gestión o usando diferentes herramientas de desarrollo.

Si en algún instante un miembro del equipo tiene que trabajar con un equipo diferente, puede experimentar el encontronazo cultural y estudiar una exclusiva forma de trabajar.

Mono-repositorio y multi-repositorio: la principal diferencia

Tras todo, ambos enfoques tienen exactamente el mismo propósito: la gestión de la base de código. Por lo tanto, todos deben solucionar exactamente los mismos retos, incluyendo la gestión de publicaciones, hacer más simple la colaboración entre los miembros del equipo, conducir inconvenientes, ejecutar pruebas, etc.

Su principal diferencia está en el instante de sus decisiones con los miembros del equipo: si se trata de solo una recompra en una etapa temprana o múltiples recompras mucho más adelante.

Evaluemos esta idea con mucho más detalle.

Gracias a que todas y cada una de las bibliotecas tienen ediciones independientes en múltiples repositorios, los editores de bibliotecas con cambios esenciales pueden proceder con seguridad asignando un número de versión principal a la última versión. Otros conjuntos pueden asegurarse de que las bibliotecas dependientes permanezcan en la versión anterior y se actualicen a la novedosa versión tan rápido como se personalice su código.

Esto permite que cada equipo responsable decida cuándo se adaptarán todas las demás bibliotecas y puede realizar cambios cualquier ocasión. Si lo hacen bastante tarde y lanzan una exclusiva versión de la biblioteca, será poco a poco más difícil cerrar la brecha entre las bibliotecas.

Como resultado, al paso que un equipo puede iterar su código de forma rápida y frecuente, es posible que otros equipos no logren ponerse cada día y terminen en bibliotecas distintas.

Por otro lado, en el entorno de monorepo, no tenemos la posibilidad de publicar una exclusiva versión de biblioteca para destruir otras bibliotecas por el hecho de que sus pruebas fallan. En un caso así, el primer grupo debe comunicarse con el segundo equipo a fin de que los cambios se combinen.

Este enfoque obliga al equipo a amoldarse completamente a todas las bibliotecas en el momento en que es requisito efectuar cambios en una biblioteca individual. Todos los equipos deben hablar entre ellos y conseguir una solución juntos.

Como resultado, el primer equipo no va a poder jugar tan rápido como esperaban, pero el código para las diferentes bibliotecas jamás va a ser diferente.

Por norma general, un enfoque de recompra múltiple puede contribuir a crear una cultura de "acción rápida y romper las reglas" entre equipos, donde los equipos flexibles e independientes tienen la posibilidad de producir a su ritmo. Por contra, el método monorepo fomenta una cultura de conciencia y cuidado, y el equipo no debe quedarse solo para resolver problemas.

Método híbrido poli-como-mono

Si no tenemos la posibilidad de elegir si utilizar un enfoque de múltiples repositorios o monorepo, hay un paso intermedio: usar múltiples repositorios y emplear ciertas herramientas para sincronizarlos, que es afín a Monorepo pero con mucho más flexibilidad.

Misión es una de esas herramientas. Organiza varios ficheros en subdirectorios y da una interfaz de línea de comandos que puede realizar exactamente el mismo comando en todos y cada uno de los archivos simultáneamente.

El repositorio de metadatos contiene información sobre qué archivos componen el proyecto. Este fichero se metaclona y luego todos los ficheros precisos se clonan de manera recursiva, lo que facilita que los nuevos integrantes del equipo inicien el proyecto inmediatamente.

Para clonar un metaarchivo y todos los ficheros múltiples que define, debemos realizar lo siguiente:

meta git clone [meta repo url]

Misión hace un git clone Para cada fichero y colóquelo en una subcarpeta:

Clona el meta elemento. (Fuente de la imagen: github.com/mateodelnorte/meta)

La implementación ha continuado desde ese momento misión exec El comando ejecuta el comando en todos y cada subcarpeta; por ejemplo, corre git checkout master Esto pasa en todos y cada fichero:

meta exec "git checkout master"

Método híbrido-mono-poli

Otra forma es dirigir el código a través del repositorio mono usado para el avance, pero copiar el código de cada biblioteca a su repositorio sin dependencia para su implementación.

Esta estrategia es común en el ecosistema PHP porque Packagist (el principal repositorio de compositores) requiere una URL de archivo público para publicar un paquete, y no hay forma de mostrar que el paquete está en un subdirectorio del fichero.

Gracias a las limitaciones de los paquetes, los proyectos PHP se pueden desarrollar aún mucho más usando Monorepo, pero tienen que implementarse empleando el método Multi-Repo.

Para conseguir esta transformación, podemos ejecutar un script git subtree split O use una de las herramientas disponibles que marchan con exactamente la misma lógica:

¿Quién usa Monorepo y Multi Repo?

Varias grandes empresas tecnológicas benefician el método monorepo, al tiempo que otras eligieron por el procedimiento monirepo.

Google plus, Facebook, GorjeoTanto Uber como Uber se han comprometido públicamente a emplear el método monorepo. Microsoft tiene el repositorio mono Git mucho más grande del mundo, que alberga el código fuente del S.O. Windows.

Por otra parte, Netflix, Amazon y Lyft son compañías conocidas que usan múltiples métodos de recompra.

En concepto de híbrido-mono-mono, Android actualiza múltiples repositorios administrados como Monorepo.

En la situacion de un híbrido mono-como-poli, Symfony cree que el código de todos sus elementos son mono-reiteraciones; lo dividen en archivos separados para su implementación (p. ej. symfony/dependency-injection y symfony/event-dispatcher.)

Ejemplos de repositorios únicos y repositorios múltiples

La cuenta de WordPress de GitHub tiene ejemplos de métodos de repositorio único y repositorio múltiple.

El editor de bloques de WordPress de Gutenberg consta de docenas de packs de JavaScript, y estos paquetes están alojados WordPress/gutenberg monorepo y Lerna consiguen publicarlos en el archivo npm.

Openverse es un motor de búsqueda de medios con licencia abierta cuyos medios Las partes primordiales están alojadas en repositorios independientes: Frontend, Catálogo y API.

Monorepo vs. Multi-Repo: ¿De qué forma escoger?

Como sucede con muchas preguntas de desarrollo, no hay una respuesta predeterminada sobre qué procedimiento utilizar. Diferentes empresas y proyectos se favorecen de una estrategia u otra gracias a sus circunstancias únicas, así como:

• ¿Qué tan grande es la base del código? ¿Tiene dentro gigabytes de datos?
• ¿Cuántas personas trabajan en el código base? ¿Es 10, 100 o 1000?
• ¿Cuántos packs habrá? ¿Es 10, 100 o 1000?
• ¿Cuántos packs debe conducir el equipo al mismo tiempo?
• ¿Qué tan conectado está el bulto?
• ¿Son diferentes lenguajes de programación? ¿Precisan disponer programa o hardware especial para funcionar?
• ¿Cuántas herramientas de implementación necesita y qué tan difícil es instalarlo?
• ¿Qué es la civilización corporativa? ¿Fomenta el trabajo en grupo?
• ¿Qué herramientas y técnicas conoce el equipo?

¿Qué enfoque debería usar en su base de código? 🤔 Haga clic aquí para obtener más información👇Realice click para twittear

resumen

Hay dos tácticas primordiales para el hosting y la administración de código: repositorio mono y repositorio múltiple. El enfoque de Monorepo requiere que el código de distintas bibliotecas o proyectos, incluso el código completo de la empresa, se almacene en un solo archivo. Un sistema de repositorios múltiples divide el código en entidades, como bibliotecas o servicios, y alberga sus códigos en repositorios independientes.

El método usado depende de muchas condiciones. Las dos estrategias tienen varias ventajas y desventajas que cubrimos en el presente artículo en particular.

¿Tiene cuestiones sobre repositorios mono o repositorios múltiples? ¡Deja tu comentario en la sección de reseñas!