Un Monorepo (del inglés 'monolithic repository') es una estrategia de gestión de código fuente donde todo el código de una organización, o una parte significativa de él, reside en un único repositorio de control de versiones. A diferencia de un 'polyrepo' (múltiples repositorios pequeños), un Monorepo consolida proyectos, bibliotecas y aplicaciones que podrían ser independientes en un solo lugar. Esto implica una estructura de directorios que organiza lógicamente los diferentes componentes, permitiendo que las herramientas de construcción y CI/CD operen sobre el conjunto completo o subconjuntos específicos de código. La gestión de dependencias internas se simplifica, ya que todos los componentes comparten el mismo historial y están disponibles en la misma 'versión' del repositorio.
Grandes empresas tecnológicas han adoptado y popularizado el concepto de Monorepo. Google es quizás el ejemplo más prominente, manteniendo la mayor parte de su código en un Monorepo masivo. Otros ejemplos incluyen Meta (Facebook), Microsoft (para Windows y Office), y Uber. Herramientas específicas como Bazel (de Google), Nx (para frameworks JavaScript/TypeScript), Lerna (para proyectos JavaScript/Node.js con múltiples paquetes), y Turborepo han surgido para gestionar la complejidad inherente a los Monorepos, optimizando las construcciones, pruebas y despliegues incrementales. Estas herramientas son cruciales para escalar el desarrollo en un Monorepo, proporcionando caching distribuido, detección de cambios inteligentes y ejecución paralela de tareas.
Para un Arquitecto de Sistemas, la elección de un Monorepo es una decisión estratégica con implicaciones significativas. Ofrece ventajas como la visibilidad global del código, la refactorización simplificada a través de límites de proyecto, la gestión de dependencias internas más sencilla y la coherencia en las versiones de las bibliotecas. Sin embargo, presenta desafíos considerables en cuanto a la escalabilidad de las herramientas (CI/CD, IDEs), la gestión de permisos, el tamaño del repositorio y la complejidad de las ramas y fusiones. Un arquitecto debe evaluar si los beneficios de la colaboración y la coherencia superan los costos de infraestructura y herramientas especializadas necesarias para mantener un Monorepo eficiente. La decisión a menudo depende del tamaño del equipo, la interdependencia de los proyectos y la madurez de la cultura de ingeniería de la organización, buscando un equilibrio entre la agilidad del desarrollo y la sobrecarga operativa.