Desarrollo y Diseño

¿Deberías Utilizar un Monorrepo?

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

El patrón es popular entre las grandes empresas tecnológicas. Google, Microsoft y Facebook son algunas de las organizaciones que utilizan monorrepos. ¿Qué hace que un monorepo sea tan atractivo?

1. La Alternativa

Monorepo se opone a multi-repo. En el patrón multi-repo se crea un nuevo repositorio para cada uno de los proyectos. Por lo general es bastante claro cuando un proyecto merece su propio repositorio.

Si estás construyendo una aplicación, podrías tener tres repositorios:

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

En este caso, todo lo que compone su empresa está dividido en distintas unidades de funcionalidad. Con un monorrepo, se abandona esa agrupación y se adopta siempre la visión agregada. Todos los activos van juntos y se versionan en consecuencia.

2. Colaboración

Una de las ventajas más citadas del monorrepo es la colaboración. En un monorepo, todo el mundo lo ve todo. Esto ayuda a la claridad, facilita la apertura y simplifica el acceso al trabajo de los demás a personas de diferentes equipos.

Las personas pueden colaborar más fácilmente en una tarea, incluso si ésta queda fuera de sus responsabilidades habituales. En un escenario de múltiples repositorios, es posible que tengas que pedir primero el acceso al repositorio correspondiente. Esto añade una fricción que el enfoque monorepo evita por completo.

Los monorrepos animan a todo el mundo a apropiarse del objetivo final más que de las piezas individuales que lo componen. Esto puede hacer que la gente se sienta más involucrada y mejor informada sobre lo que está pasando. Puede que un desarrollador de aplicaciones nunca toque los componentes del servidor, pero puede “sentir” cómo evolucionan junto con su propio trabajo.

3. Facilidad de Abstracción

Los monorrepos también simplifican la abstracción del 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 múltiples repositorios, necesitarías crear un nuevo repositorio y luego referenciarlo en los otros. Eso podría ser mediante la construcción de un paquete, o mediante el uso de submódulos Git. De cualquier manera, se necesita mucho trabajo antes de que tu código abstraído pueda ser devuelto a los proyectos de los que procede.

El proceso es más sencillo si tienes un monorepo. Puedes mover el código a un directorio que tenga sentido, y luego importarlo donde sea necesario. Una “abstracción” es cuestión de segundos. Hay una comodidad similar cuando llega el momento de documentar el código: Puedes añadir la documentación en tu sistema de documentación compartido.

Los multirepositorios también presentan obstáculos prácticos a la hora de 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 se traduce en una sobrecarga aún mayor cuando un jefe de equipo debe aprobar la nueva biblioteca y crear un repositorio. Los monorrepos ayudan a los desarrolladores individuales a crear código reutilizable al eliminar los procesos de abstracción especiales.

Además de crear la abstracción, los monorrepos simplifican el mantenimiento de los módulos compartidos. No es necesario actualizar cada consumidor de un paquete cada vez que se actualiza. Todas las dependencias existen en la misma base de código, por lo que se puede hacer referencia a ellas sin necesidad de un gestor de paquetes o de un sistema de versiones dedicado.

4. Velocidad de Desarrollo

El uso de un monorepo puede acelerar la velocidad de desarrollo.

Los monorrepos reducen las acciones duplicadas. Si necesita refactorizar, es un único Buscar y Reemplazar para aplicar el cambio en toda la base de código. Hay menos cambios entre proyectos y menos pull requests que revisar.

Los colaboradores tienen más capacidad de autogestión. Como la información no está aislada en los repositorios del equipo, la gente está mejor equipada para buscar los detalles que necesitan. Esto puede reducir las idas y venidas durante la planificación y revisión del código.

Estas características también ayudan cuando se refactoriza un sistema existente. Tratar de dividir una aplicación heredada en su “frontend” y “backend” puede ser un enfoque equivocado. Los cambios en una parte afectarán inevitablemente a la otra, por lo que habrá que reconciliar continuamente los dos repositorios. El uso de un monorrepo le ayuda a refactorizar rápidamente grandes extensiones de la base de código, sabiendo que está afectando a todo el sistema en lugar de a componentes fragmentados.

5. ¿Para quiénes son los monorrepos?

Los monorrepos 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. Los monorrepos funcionan mejor a una escala en la que habría una ineficiencia perceptible con un enfoque de múltiples repositorios.

Los monorrepos no son lo mismo que los monolitos. Un monolito suele describir una aplicación en la que las capas de datos y de presentación están entremezcladas. Todo el sistema se despliega cada vez que se realiza un cambio.

Los monorrepos generalmente encapsulan múltiples sistemas. Tienen múltiples 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 monorrepos están pensados para facilitar el intercambio de código y la refactorización. No están pensados para dar lugar a un sistema estrechamente acoplado que esté artificialmente unido.

El patrón no es para todos los equipos. En muchos casos, será más fácil trabajar con múltiples repositorios. Suelen parecer más lógicos y pueden ser más fáciles de manejar. No tendrás que resolver conflictos de fusión en partes dispares del sistema y es más fácil manejar las versiones. Los pipelines CI serán más rápidos, ya que no tendrás que probar cada proyecto en cada pipeline.

Los repositorios dedicados también presentan un historial de commits más limpio. Los historiales de los monorrepositorios están contaminados por los commits realizados en cada proyecto dentro del repositorio. Esto dificulta el seguimiento de la evolución de los componentes individuales.

Los repositorios múltiples 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 los repositorios y los proyectos. Puede ser engorroso hacer un seguimiento de las incidencias y pull requests en un monorepo. Tendrás que utilizar diligentemente las etiquetas para asignar cada problema al proyecto adecuado.

Por último, ten en cuenta que la mayoría de las organizaciones con monorepos utilizan una infraestructura especializada para soportarlos. Git no está diseñado para monorepos, y puede tener problemas si alcanzas una escala suficiente. Tener millones de objetos en el historial de confirmaciones puede provocar ralentizaciones cuando Git tenga que recorrer el gráfico.

Resumen

El patrón monorepo simplifica el intercambio de código y mejora la visibilidad de tus activos. Esto tiene el coste de un historial de confirmaciones limpio, un mayor riesgo de conflictos de fusión y un mal soporte de las herramientas más populares. También podría sufrir problemas de rendimiento a medida que el monorepo crece.

La transparencia de un monorepo no será apropiada en todos los escenarios. Si se encuentra en un entorno estrictamente regulado, podría necesitar utilizar repositorios individuales para poder aplicar los controles de acceso adecuados. Los monorrepos también aumentan el riesgo en caso de pérdida o robo del dispositivo de un empleado. Las personas con acceso físico podrían ver todo su código en lugar de sólo los proyectos relevantes para ese individuo.

La decisión de utilizar un monorrepo debe basarse en tus propios proyectos, sus dependencias entre proyectos y los miembros de tu equipo. No te fijes en las grandes empresas tecnológicas y esperes observar sus éxitos en tus propios proyectos. Hay más cosas en una buena cultura de código que el tipo de repositorio que se utiliza. Los monorepos tienen más sentido cuando la gente ya colabora libremente entre proyectos por su propia voluntad.

Etiquetas

Acerca del Autor

Andres

Agregar un Comentario

Clic Aqui para Publicar un Comentario