Hispanopedia Wiki
Articulo de referencia

Monorepositorio

En los sistemas de control de versiones , un monorepo o monorepositorio (" mono " significa "único" y "repo" es la abreviatura de " repositorio ") es una estrategia de desarroll...

Hispanopedia WikiContenido en espanolLectura gratuita

En los sistemas de control de versiones , un monorepo o monorepositorio (" mono " significa "único" y "repo" es la abreviatura de " repositorio ") es una estrategia de desarrollo de software en la que el código de varios proyectos se almacena en el mismo repositorio. [ 1 ] Esta práctica se remonta al menos a principios de la década de 2000, [ 2 ] cuando se la denominaba comúnmente código base compartido. [ 2 ] Google , [ 3 ] Meta , [ 4 ] Microsoft , [ 5 ] Uber , [ 6 ] Airbnb y Twitter [ 7 ] emplean monorepos muy grandes con diversas estrategias para escalar los sistemas de compilación y el software de control de versiones con un gran volumen de código y cambios diarios.

Un concepto relacionado es el de aplicación monolítica , pero mientras que un monolito combina sus subproyectos en un único proyecto grande, un monorepo puede contener múltiples proyectos independientes. [ 8 ] [ 9 ] [ 10 ]

Ventajas

Existen varias ventajas potenciales de un monorepo sobre los repositorios individuales: [ 3 ] [ 11 ]

Facilidad para reutilizar el código
Funcionalidades o protocolos de comunicación similares pueden abstraerse en bibliotecas compartidas e incluirse directamente en los proyectos, sin necesidad de un gestor de paquetes de dependencias .
Gestión de dependencias simplificada
En un entorno de repositorios múltiples, donde varios proyectos dependen de una dependencia de terceros, dicha dependencia podría descargarse o compilarse varias veces. En un monorepositorio, la compilación se puede optimizar fácilmente, ya que todas las dependencias referenciadas se encuentran en el mismo código fuente.
Confirmaciones atómicas
Cuando los proyectos que trabajan juntos se encuentran en repositorios separados, las versiones deben sincronizar qué versiones de un proyecto funcionan con el otro. Y en proyectos suficientemente grandes, gestionar versiones compatibles entre dependencias puede convertirse en un infierno de dependencias . [ 6 ] En un monorepo este problema se puede evitar, ya que los desarrolladores pueden modificar varios proyectos de forma atómica. [ 12 ]
Refactorización de código a gran escala
Dado que los desarrolladores tienen acceso a todo el proyecto, las refactorizaciones pueden garantizar que cada parte del proyecto siga funcionando después de la refactorización.
Colaboración entre equipos
En un monorepo que utiliza dependencias de código fuente (dependencias que se compilan desde el código fuente), [ 7 ] los equipos pueden mejorar los proyectos en los que trabajan otros equipos. Esto conduce a una propiedad de código flexible .

Limitaciones y desventajas

Pérdida de información de versión
Aunque no es obligatorio, algunas compilaciones de monorepo utilizan un único número de versión para todos los proyectos del repositorio. Esto conlleva una pérdida del versionado semántico por proyecto . [ 13 ]
Falta de control de acceso por proyecto
Con repositorios divididos, el acceso a un repositorio se puede otorgar según la necesidad. Un monorepo permite el acceso de lectura a todo el software del proyecto, lo que podría presentar nuevos problemas de seguridad. [ 14 ] Cabe señalar que existen sistemas de control de versiones en los que esta limitación no representa un problema. Por ejemplo, cuando se utiliza Subversion , es posible descargar cualquier parte del repositorio (incluso un solo directorio), y se puede usar la autorización basada en rutas para restringir el acceso a ciertas partes del repositorio.
Se necesita más almacenamiento por defecto
Con los repositorios divididos, por defecto solo se descarga el proyecto de interés. Con un monorepo, por defecto se descargan todos los proyectos. Esto puede ocupar una cantidad considerable de espacio de almacenamiento. Si bien algunos sistemas de control de versiones cuentan con un mecanismo para realizar una descarga parcial, [ 15 ] [ 16 ] [ 17 ] hacerlo anula algunas de las ventajas de un monorepo.

Desafíos de escalabilidad

Las empresas con grandes proyectos se han topado con obstáculos con los monorepos, específicamente en lo que respecta a las herramientas de compilación y los sistemas de control de versiones. [ 4 ] El monorepo de Google, considerado el más grande del mundo, cumple con la clasificación de un sistema de ultra gran escala [ 3 ] y debe manejar decenas de miles de contribuciones diarias en un repositorio de más de 80 terabytes. [ 18 ]

Software de control de versiones escalable

Las empresas que utilizaban o migraban a software de control de versiones existente descubrieron que dicho software no podía gestionar de forma eficiente la cantidad de datos necesaria para un monorepositorio grande. Facebook y Microsoft optaron por contribuir o bifurcar el software de control de versiones existente, Mercurial y Git respectivamente, mientras que Google acabó creando su propio sistema de control de versiones.

Durante más de diez años, Google dependió de Perforce alojado en una sola máquina. En 2005, los servidores de compilación de Google podían bloquearse hasta por 10 minutos. Google mejoró este tiempo a entre 30 segundos y 1 minuto en 2010. [ 19 ] Debido a problemas de escalabilidad, Google finalmente desarrolló su propio sistema interno de control de versiones distribuido, denominado Piper . [ 3 ]

Facebook tuvo problemas de rendimiento con el sistema de control de versiones Mercurial e hizo contribuciones ascendentes al cliente, [ 20 ] y en enero de 2014 lo hizo más rápido que una solución competidora en Git. [ 21 ]

En mayo de 2017, Microsoft anunció que prácticamente todos sus ingenieros de Windows utilizan un monorepo de Git. [ 5 ] En la transición, Microsoft realizó importantes contribuciones al cliente de Git para eliminar el acceso innecesario a archivos y mejorar el manejo de archivos grandes con el Sistema de Archivos Virtuales para Git . [ 22 ]

Escalado de software de compilación

Pocas herramientas de compilación funcionan bien en un monorepo, [ 7 ] y los flujos donde las compilaciones y las pruebas de integración continua de todo el repositorio se realizan al confirmar cambios causarán problemas de rendimiento. [ 13 ] [ 14 ] Un sistema de compilación que procesa las dependencias como un grafo dirigido (como Buck , Bazel , Please o Pants) resuelve esto compartimentando cada compilación o prueba al área de desarrollo activa. [ 23 ]

Twitter comenzó el desarrollo de Pants en 2011, ya que tanto Buck de Facebook como Bazel de Google eran de código cerrado en ese momento. [ 24 ] Twitter liberó el código fuente de Pants en 2012 bajo la licencia Apache 2.0. [ 25 ]

Please es un sistema de compilación basado en Go ; fue desarrollado en 2016 por Thought Machine , cuyos desarrolladores se inspiraron en Bazel de Google y estaban insatisfechos con Buck de Facebook. [ 26 ]

Referencias

  1. ↑ "Infraestructura como código | Segunda edición" . Thoughtworks . 25 de febrero de 2021. Consultado el 1 de diciembre de 2022 .
  2. 1 2 Mark "Nurgle." Collins (2001). Programación de juegos en Linux . Prima Tech. ISBN 978-0-7615-3255-2OCLC 1044194694 .​ 
  3. 1 2 3 4 Potvin, Rachel; Levenberg, Josh (julio de 2016). "Por qué Google almacena miles de millones de líneas de código en un solo repositorio" . Communications of the ACM . 59 (7): 78– 87. doi : 10.1145/2854146 . Recuperado el 20 de julio de 2018 .
  4. 1 2 Goode, Durham; Rain (7 de enero de 2014). "Escalando Mercurial en Facebook – Código de Facebook" . Código fb . Recuperado el 24 de julio de 2018 .
  5. 1 2 Lardinois, Frederic (24 de marzo de 2017). "Microsoft ahora usa Git y GVFS para desarrollar Windows" . TechCrunch . Recuperado el 20 de julio de 2018 .
  6. 1 2 Aimee Lucido (7 de abril de 2017). Uber Technology Day: Monorepo a Multirepo y viceversa . Recuperado el 24 de julio de 2018 .
  7. 1 2 3 Dorothy Ordogh (5 de abril de 2018). Pants and Monorepos . Recuperado el 24 de julio de 2018 .
  8. ↑ Reece, Brock (7 de noviembre de 2017). "De Monolith a Monorepo" . De Monolith a Monorepo. Desde sus inicios en Croud . Recuperado el 19 de marzo de 2019 .
  9. ↑ Savkin, Victor (14 de agosto de 2019). "Conceptos erróneos sobre los monorepos: Monorepo != Monolith" . blog.nrwl.io. Consultado el 16 de junio de 2020 . 
  10. ↑ Oberlehner, Markus (12 de junio de 2017). "Monorepos en estado salvaje" . Recuperado el 25 de julio de 2018 .
  11. ↑ Brousse, Nicolas (2019). «El problema de los monorepo y los polirepo en las grandes empresas» . Actas de la Conferencia Complementaria de la 3.ª Conferencia Internacional sobre Arte, Ciencia e Ingeniería de la Programación . pp. 1–4 . doi : 10.1145/3328433.3328435 . ISBN  9781450362573. S2CID 201670751 . Consultado el 7 de septiembre de 2019 . 
  12. ↑ Santacroce, Fernando; Olsson, Aske; Voss, Rasmus; Narebski, Jakub (2016). Git: Dominar el control de versiones . Packt Publishing Ltd. pág. 756.ISBN​  9781787122796.
  13. 1 2 Farina, Matt. "Peligros de los proyectos monorepo - DZone DevOps" . DZone . Consultado el 20 de julio de 2018 .
  14. 1 2点融黑帮 (16 de agosto de 2017). "浅谈monorepo" [ Hablando de monorepo ] . Sohu (en chino) . Consultado el 20 de julio de 2018 .
  15. ↑ clonación parcial de git
  16. ↑ Libro Svn: Directorios dispersos
  17. ↑ Perforce: Clon
  18. ↑ Metz, Cade (16 de septiembre de 2015). "Google tiene 2 mil millones de líneas de código, y todo está en un solo lugar" . WIRED . Consultado el 20 de julio de 2018 .
  19. ↑ Bloch, Dan. "Todo sigue en un solo servidor: Perforce a escala" (PDF) . Consultado el 23 de julio de 2018 .
  20. ↑ Claburn, Thomas. "Facebook está escribiendo un servidor Mercurial en Rust. Esto no es un simulacro" . The Register . Consultado el 20 de julio de 2018 .
  21. ↑ Blewitt, Alex (9 de enero de 2014). "Facebook hace que Mercurial sea más rápido que Git" . InfoQ . Consultado el 24 de julio de 2018 .
  22. ↑ Bright, Peter (24 de mayo de 2017). "Windows cambia a Git casi por completo: 8500 confirmaciones y 1760 compilaciones diarias" . Ars Technica . Consultado el 20 de julio de 2018 .
  23. ↑ Hammant, Paul; Smith, Steve. "Desarrollo basado en troncos" . trunkbaseddevelopment . Consultado el 24 de julio de 2018 .
  24. ↑ Mohilo, Dominik (10 de junio de 2016). "8 Build-Tools im Vergleich: Ant – Buildr – Maven – Bazel – Buck – Gradle – Pants – sbt - JAXenter" [ 8 build tools compared: Ant - Buildr - Maven - Bazel - Buck - Gradle - Pants - sbt ] . JAXenter (en alemán) . Consultado el 20 de julio de 2018 .
  25. ↑ Moore, Madison (3 de mayo de 2016). "GitLab lanza correcciones de seguridad, Pants 1.0 e integración de Sauce Labs para JIRA: resumen de noticias de SD Times: 3 de mayo de 2016 - SD Times" . SD Times . Consultado el 20 de julio de 2018 .
  26. ↑ Ebden, Peter (diciembre de 2017). "Por favor: el sistema de compilación de Thought Machine" . Blog. Thought Machine . Archivado del original el 28 de diciembre de 2019.