¿Debería usar un Monorepo? – CloudSavvy IT

Tecnología junio 5, 2021
ilustración de la nube
Shutterstock / Andrey Suslov

El patrón monorepo utiliza un único repositorio de control de versiones para todos sus proyectos y activos. Agruparás tus archivos de configuración del lado del servidor, frontend e infraestructura en un repositorio al que todos contribuyen. ¿Deberías usarlo?

El patrón es popular entre las grandes empresas de tecnología. Google, Microsoft y Facebook se encuentran entre las organizaciones que utilizan monorepos. ¿Qué hace que un monorepo sea tan atractivo?

La alternativa

Monorepo se opone a los repositorios múltiples. El patrón de repositorios múltiples le permite crear un nuevo repositorio para cada uno de sus proyectos. Por lo general, es bastante claro cuándo un proyecto merece su propio repositorio.

Si está creando una aplicación, es posible que tenga tres repositorios:

  • Código del lado del servidor: Su API (posiblemente con repositorios adicionales para esquemas de base de datos y documentación).
  • Proyecto de Android: La compilación de Android de su aplicación, usando Java o Kotlin.
  • Proyecto iOS: Objective-C o Swift para su aplicación iOS.

Aquí, todo lo que constituye su negocio se divide en distintas unidades de funcionalidad. Con un monorepo, abandonas esa agrupación y siempre tomas la vista agregada. Todos sus activos pertenecen juntos y están versionados en consecuencia.

Colaboración

Uno de los beneficios de monorepo más citados se refiere a la colaboración. En un monorepo, todo el mundo ve todo. Esto ayuda a la claridad, facilita la apertura y facilita que las personas de diferentes equipos accedan al trabajo de los demás.

Las personas pueden trabajar juntas más fácilmente en una tarea, incluso si queda fuera de sus responsabilidades habituales. En un escenario de repositorios múltiples, es posible que primero deba solicitar acceso al repositorio relevante. Esto agrega fricciones que el enfoque de monorepo evita por completo.

Monorepos anima a todos a ser dueños del objetivo final en lugar de las piezas individuales que lo componen. Esto puede hacer que las personas se sientan más involucradas y mejor informadas sobre lo que está sucediendo. Es posible que un desarrollador de aplicaciones nunca toque los componentes del servidor, pero puede “sentirlos” evolucionar junto con su propio trabajo.

Facilidad de abstracción

Monorepos también simplifica la abstracción de código. Es común terminar con una funcionalidad similar en sus componentes de backend y frontend. Tiene sentido abstraer esto en una biblioteca compartida.

En el paradigma de repositorios múltiples, necesitaría crear un nuevo repositorio y luego hacer referencia a él en los demás. Eso podría ser compilando un paquete o usando submódulos de Git. De cualquier manera, se necesita mucho trabajo antes de que su código abstraído pueda retroalimentarse en los proyectos de los que se obtuvo.

El proceso es más sencillo si tienes un monorepo. Puede mover el código a un directorio que tenga sentido y luego importarlo donde sea necesario. Una “abstracción” tarda unos segundos. Existe una conveniencia similar cuando llega el momento de documentar el código: puede agregar los documentos a su sistema de documentación compartida.

Los repositorios múltiples también presentan obstáculos prácticos al abstraer el código. Un miembro del equipo de desarrollo a menudo carece de los permisos necesarios de GitLab, GitHub o Bitbucket para crear un nuevo repositorio. Esto resulta en gastos generales aún mayores cuando un líder de equipo debe aprobar la nueva biblioteca y configurar un repositorio. Monorepos ayuda a los desarrolladores individuales a crear código reutilizable eliminando procesos especiales de abstracción.

Más allá de creando la abstracción, monorepos simplifican el mantenimiento de módulos compartidos. No es necesario que actualice cada consumidor de un paquete cada vez que lo actualice. Todas las dependencias existen en la misma base de código, por lo que puede hacer referencia a ellas sin un administrador de paquetes o control de versiones dedicado.

Velocidad de desarrollo

El uso de un monorepo puede acelerar la velocidad de desarrollo. Hemos abordado esto en las secciones anteriores, pero vale la pena prestarle más atención.

Los monorepos reducen las acciones duplicadas. Si necesita refactorizar, es un solo Buscar y Reemplazar para aplicar el cambio en la base de código. Hay menos cambios entre proyectos y menos solicitudes de extracción para revisar.

A los contribuyentes se les da más capacidad de auto-servicio. Como la información no se almacena en depósitos de equipos, las personas están mejor equipadas para buscar los detalles que necesitan. Esto puede reducir los vaivenes durante la planificación y revisión del código.

Estas características también ayudan cuando está refactorizando un sistema existente. Intentar dividir una aplicación heredada en su “frontend” y “backend” puede ser el enfoque incorrecto. Los cambios en un lado afectarán inevitablemente al otro, por lo que conciliará continuamente los dos repositorios. El uso de un monorepo le ayuda a refactorizar rápidamente grandes franjas del código base, sabiendo que está afectando a todo el sistema en lugar de a los componentes por partes.

¿Para quién son los Monorepos?

Los monorepos son una buena opción para equipos grandes con múltiples proyectos. Los beneficios no son necesariamente evidentes con un puñado de proyectos pequeños. Monorepos funciona mejor a una escala en la que habría una ineficiencia perceptible con un enfoque de repositorios múltiples.

Los monorepos no son lo mismo que los monolitos. Un monolito generalmente describe una aplicación donde los datos y las capas de presentación están entremezclados. Todo el sistema se implementa cada vez que se realiza un cambio.

Los monorepos generalmente encapsulan múltiples sistemas. Tienen varios artefactos de salida, como una API, un sitio web y una aplicación móvil. No es necesario producir todos los artefactos para cada cambio. Los monorepos están destinados a facilitar el intercambio de código y la refactorización. No están destinados a dar como resultado un sistema estrechamente acoplado que esté unido artificialmente.

El patrón no es para todos los equipos. En muchos casos, será más fácil trabajar con varios repositorios. A menudo se sienten más lógicos y pueden ser más fáciles de manejar. No necesitará resolver conflictos de fusión en partes dispares del sistema y es más fácil manejar las versiones. Las canalizaciones de CI serán más rápidas, ya que no probará todos los proyectos de cada canalización.

Los repositorios dedicados también presentan un historial de confirmaciones más limpio. Las historias de Monorepo están contaminadas por los compromisos realizados con cada proyecto dentro del repositorio. Esto hace que sea más difícil rastrear cómo han evolucionado los componentes individuales.

Varios repositorios son más fáciles de integrar con software de control de versiones como GitHub y GitLab. Estas herramientas asumen un mapeo uno a uno entre repositorios y proyectos. Puede ser engorroso rastrear problemas y extraer solicitudes en un monorepo. Deberá utilizar etiquetas con diligencia para adaptar cada problema al proyecto correspondiente.

Finalmente, tenga en cuenta que la mayoría de las organizaciones con monorepos están utilizando infraestructura especializada para respaldarlos. Git no está diseñado para monorepos, y puede tener problemas si alcanzas la escala suficiente. Tener millones de objetos en su historial de confirmaciones puede resultar en ralentizaciones cuando Git necesita recorrer el gráfico.

Resumen

El patrón monorepo simplifica el uso compartido de código y mejora la visibilidad de sus activos. Esto tiene el costo de un historial de confirmaciones limpio, un mayor riesgo de conflictos de fusión y un soporte deficiente de las herramientas populares. También podría sufrir problemas de rendimiento a medida que crece el monorepo.

La transparencia de un monorepo no será apropiada en todos los escenarios. Si se encuentra en un entorno estrictamente regulado, es posible que deba utilizar repositorios individuales para poder aplicar los controles de acceso adecuados. Los monorepos también aumentan el riesgo si el dispositivo de un empleado se pierde o es robado. Las personas con acceso físico podrían ver todo su código en lugar de solo los proyectos relevantes para esa persona.

La decisión de utilizar un monorepo debe basarse en sus propios proyectos, sus dependencias entre proyectos y los miembros de su equipo. No mire a las grandes empresas de tecnología y espere observar sus éxitos en sus propios proyectos. Hay más en una buena cultura de código que el tipo de repositorio que usa. Monorepos tiene más sentido donde las personas ya están colaborando libremente en proyectos cruzados por su propia voluntad.