Developer Journey: Monorepos vs Polyrepos

Hola a todos. Me gustaría comenzar contándoles una historia sobre un tipo llamado Dan. Así que este es Dan aquí mismo. Es mecánico y su trabajo es reparar naves espaciales. Así que puedes verlo aquí sentado en este bar del puerto espacial, ya sabes, está bebiendo una cerveza que es técnicamente derivada de hongos. Pero solo está sentado, ya sabes, está disfrutando, lo está pasando bien.

Y Dan es realmente una metáfora de todos nosotros, los desarrolladores. Y como cualquier desarrollador durante el día, Dan pasará de ser cautelosamente optimista a caer en un pozo de desesperación y depresión absoluta. Pero saldrá del otro lado sintiéndose como si hubiera entendido todo y está en la cima del mundo.

Mi nombre es Max y personalmente he pasado por ese ciclo de desilusión y comprensión muchas veces en mi vida. Y espero poder hacerlo un poco más fácil para ustedes hoy. Así que hablemos de monorepos, como probablemente habrán adivinado por el título. Y trabajo en una empresa llamada NX donde construimos herramientas de monorepo. Y también trabajo dentro de un monorepo todo el día, todos los días. Así que esa es mi perspectiva al respecto.

Solo para darles una idea de a qué se enfrentan, voy a comenzar hablando sobre polyrepos, lo que hacen bien, pero también dónde fallan. Luego hablaré sobre monorepos y qué problemas resuelven, así como por qué necesitas buenas herramientas de monorepo especialmente a gran escala. Así que en esta charla, cada nave espacial es una analogía de un repositorio. Así que en su primer día de trabajo, Dan se une a una flota de naves espaciales, de hecho. Ya sabes, hay algunas al frente, están luchando contra piratas espaciales, están explorando, están haciendo cosas geniales de personaje principal. Hay algunas en el medio, transportando tripulación, manejando reparaciones y similares. Y luego hay algunos barcos en la parte trasera de la flota, ya sabes, manejando suministros con el hogar y las comunicaciones. Así que todos estos barcos, tienen sus responsabilidades individuales, pero también están todos conectados de alguna manera.

Y diría que esta es una forma perfectamente lógica de organizar una flota de naves espaciales. Y también tiene sentido en el mundo del código. En el mundo del código, llamaría a este enfoque un polyrepo. Donde cada equipo o proyecto tiene su propio repositorio alojado en GitHub o similar. Y lo que estamos tratando de lograr y por qué esta es una forma tan popular de desarrollar software es la autonomía del equipo que se obtiene. Así que cada equipo tiene expertos en su dominio y para sus proyectos, ¿verdad? Y son libres de tomar decisiones. Por ejemplo, tienen libertad tecnológica.

En este caso, hay dos aplicaciones de React y una aplicación de Angular. Comparten algo de código con TypeScript, y hay un backend escrito en Kotlin. Debido a que esto está estructurado tan bien, en realidad es mucho más fácil obtener una visión general y comprender lo que está haciendo todo tu sistema y cómo está estructurado, en lugar de tener solo una gran bola de barro sin una estructura interna discernible.

Así que, para resumir, diría que los polyrepos son geniales. Porque ofrecen autonomía de equipo, libertad tecnológica y una arquitectura claramente separada. Pero si los polyrepos son tan geniales, entonces ¿por qué estoy aquí? ¿Por qué estoy dando esta charla a muchos repos, verdad?

Bueno, digamos que la página de inicio y el equipo de la aplicación web quieren compartir algo de código. Quieren compartir algunos hooks de React. ¿Cómo hacemos esto? Bueno, crearían un repositorio para esos hooks. Tendrían que configurar la publicación, construcción, linting, pruebas, pipeline de CI. Tienen que hacer PRs a los repos para consumir esa biblioteca, y luego tal vez pasar por esos pasos un par de veces para iterar hasta que todo funcione. Como puedes imaginar, eso es mucho trabajo adicional. Es mucho trabajo por el que los desarrolladores no quieren pasar.

Así que dirán, ya sabes, solo esta vez copiaré este código. Estará bien. Y, por supuesto, no es solo una vez. Sucede todo el tiempo. Y ahora ese código vive en rondas completamente separadas. Si un equipo encuentra y corrige un error, el otro equipo podría ni siquiera saber que existe. Así que con el tiempo, las inconsistencias y los errores comienzan a infiltrarse en tu sistema a través de la duplicación de código.

Y como puedes imaginar, esto no escala bien, ¿verdad? La gente va a estar en diferentes versiones de bibliotecas con miedo de actualizar porque actualizar siempre es un riesgo. Pero incluso si solo miramos la parte del front-end, digamos que una de esas actualizaciones requirió una actualización a una versión de React. Mientras todos comenzaron con versiones sincronizadas, ya sabes, la vida se interpone. Algunas personas tienen bloqueadores. Algunas personas realmente necesitan actualizar para solucionar algún problema o error. Y mientras todos comenzaron con versiones sincronizadas, con el tiempo, emergen. En este sistema, no hay nada que impida a alguien importar un componente de React 17 en una aplicación de React 15. Y quién sabe qué podría pasar cuando hagas eso. Esos podrían funcionar perfectamente bien, o podrían romperse más tarde de las maneras más espectaculares incluso de las maneras más sutiles.

Lo mismo ocurre con las relaciones front-end y back-end. Digamos que los equipos de front-end y back-end, acuerdan alguna interfaz compartida que usan para comunicarse. Si el equipo de back-end cambia eso sin coordinar bien y sin comunicarse con los equipos de front-end, podrían simplemente romperlos completamente en producción. Así que necesitas alguna forma de manejar eso, banderas de características, APIs de versión, cosas así. Así que lo que esto resulta, en última instancia, es este tipo de estado constante de miedo donde todos están en sus pequeñas islas, con miedo de actualizar y romper su equilibrio cuidadosamente elaborado. Así que mientras la autonomía del equipo es genial, viene con el costo, en este caso, de aislamiento. Y el aislamiento perjudica la colaboración.

Para resumir, los polyrepos tienen problemas debido al intercambio de código ineficiente, alta duplicación de código, gestión de dependencias compleja, todo lo cual resulta en última instancia en aislamiento. Así que Dan ha pasado por todo esto. Está en el fondo del pozo del que te hablaba antes. Y ha terminado. Acaba de pasar semanas tratando de coordinar entre diferentes equipos y solucionando problemas que no deberían haber estado allí, pasando horas en reuniones. Y está tratando de ahogar sus penas, y puedo relacionarme. Pero luego descubre un nuevo enfoque, el Monorepo.

Así que en lugar de tener esta flota de naves espaciales, todas en realidad trabajan juntas en una gran nave espacial. Todavía hay tripulaciones que pueden actuar de manera autónoma, pero todas trabajan juntas en una nave espacial.

Y aunque eso pueda parecer un enfoque abrumador al principio, en realidad tiene muchos beneficios, que vamos a aprender junto con Dan. ¡Hola! Bien, antes de profundizar demasiado en esto, quiero alinearme sobre lo que realmente es un Monorepo. Me gusta esta definición, que dice, un Monorepo es un único repositorio que contiene múltiples proyectos distintos con relaciones bien definidas. Es un poco complicado, así que vamos a profundizar en ello.

El primero tiene sentido, ¿verdad? Múltiples proyectos distintos. Si solo tienes un repositorio con un proyecto en él, eso no es un Monorepo. Eso probablemente sea un monolito de algún tipo sin una estructura interna discernible. Así que necesitas múltiples proyectos. Pero incluso si solo pones tres aplicaciones en una carpeta, eso no es un Monorepo. Eso es solo co-ubicación. Necesitas esas relaciones bien definidas. Así que tan pronto como comienzas a desglosar piezas de tu código, definiendo cómo estas diferentes piezas dependen unas de otras, se relacionan entre sí, entonces tienes un Monorepo. Y viene con muchos beneficios. Vamos a profundizar en ello.

Lo primero de lo que quiero hablar es de los cambios atómicos. ¿Recuerdas todo lo que estaba involucrado en compartir algo de código en la configuración de PolyRepo? Tienes que configurar un repo, linting, testing, publicación, hacer PRs, hacer más PRs, configurar CI, todo eso. Es mucho trabajo extra.

La gente no quiere pasar por eso. Sin embargo, en un Monorepo, puedes simplemente hacer un cambio en una biblioteca. Y debido a que todas esas aplicaciones importan directamente de esa carpeta, simplemente consumen esos cambios de inmediato.

Así que eso significa que puedes hacer un solo PR que realice todos los cambios necesarios en todo el sistema. Luego puedes probar todos esos cambios juntos. Así que eso significa que para cualquier commit dado en un Monorepo, puedes asegurarte de que todo tu sistema esté en un estado donde todo funcione junto. No más lidiar con versiones y lanzar algo esperando que funcione. Así que esto hace que compartir código sea mucho más fácil. Vimos todo lo que se requería antes. Ahora puedes simplemente crear una biblioteca, importarla, y eso es todo.

Y eso significa que la duplicación de código disminuirá mucho. La gente nunca tuvo algo en contra de compartir código. Solo que el trabajo extra era tan alto que no lo hacían. Si lo haces fácil para ellos, lo harán con gusto. Así que la duplicación de código disminuirá, al igual que el número de errores e inconsistencias en tu base de código. Porque todo está en un solo repositorio, puedes definir realmente el nivel raíz de React y TypeScript u otras versiones. Así que eso significa que cada aplicación puede usar la misma versión. Ya no tienes que preocuparte por esas extrañas inconsistencias.

Si importas una aplicación de React 15 en un componente de React 70, esto hace que sea mucho más fácil agregar nuevos proyectos también al monorepo. Toda la infraestructura ya está ahí. Todas las dependencias, la tubería de CI, sabes cómo construir y publicar, lint y test y todo. Simplemente pones la nueva aplicación allí, importas de algún código compartido y comienzas de inmediato.

Esto me lleva a mi siguiente punto, que es el tooling consistente. Como puedes imaginar, en el mundo de Polyrepo, cada uno encuentra sus propias soluciones a los problemas, ¿verdad? Eso es bueno. Queremos la autonomía del equipo. Pero ciertas cosas podrían estandarizarse. Si podemos lograr que ciertos equipos o todos los equipos estén de acuerdo en una forma compartida de construir, publicar, probar, hacer linting de su código, entonces la carga mental para los desarrolladores en cada uno de esos equipos disminuye considerablemente.

Puedo ir a cualquier equipo y entenderé cómo se construye su código, cómo trabajar en su proyecto. Y eso significa que con gusto iré y contribuiré en toda la pila, así como los desarrolladores tendrán una experiencia de desarrollo consistente dondequiera que trabajen. Así que para resumir, diría que los monorepos ayudan con tres grandes cosas, velocidad, seguridad y movilidad. Y todas esas cosas de las que acabo de hablar, contribuyen aquí de varias maneras. No voy a repasarlas todas. Pero tomemos solo los Commits Atómicos como ejemplo. Porque puedo hacer cambios con un solo PR en toda la pila, ya no tengo que coordinar lanzamientos, esperar a que las prioridades de otros equipos se alineen con las mías. Puedo hacer todos los cambios en un solo PR, lo cual es mucho más rápido. Así que la velocidad aumenta. Porque puedo probar todo en ese único PR juntos, puedo asegurarme de que todo el sistema esté en un estado válido. Así que la fiabilidad y seguridad de mi código aumentarán. Y porque es tan fácil hacer un cambio que afecta a proyectos en toda la pila, la gente será mucho más propensa a hacerlo, y la movilidad de los desarrolladores aumentará. Así que los monorepos son geniales. Y espero que todos estén de acuerdo conmigo en eso.

Pero quiero hacer una pequeña advertencia, que es si tus equipos se odian entre sí, no les gustará trabajar juntos en un monorepo. Y eso tiene sentido, ¿verdad? Pero lo que a menudo preocupa a la gente en un monorepo es estar demasiado acoplado a otros equipos, especialmente si no les gustan. Eso es en realidad un malentendido en muchos casos. En un monorepo, aún puedes tener control total sobre quién contribuye a tu código, qué herramientas usas, cuándo lo despliegas. Pero hay una validez en este punto, en esta preocupación. Se requiere un cierto nivel de colaboración básica. ¿Verdad? ¿Necesitamos estar de acuerdo en la misma herramienta de monorepo? Por una vez, probablemente necesites estar de acuerdo en el mismo proveedor de CI. Y si tus equipos se odian, eso podría no suceder. Sin embargo, si tus equipos se odian, probablemente tengas un problema de organización y de personas, no un problema tecnológico, y no puedo ayudarte con eso. Pero me permite hacer un punto muy importante, que es que los monorepos no son una cuestión de todo o nada. La mayoría de ustedes probablemente no son Google.

Necesitas juntar todo en un gigantesco monorepo. Nosotros mismos, construimos herramientas de monorepo, ¿verdad? Sin embargo, tenemos múltiples monorepos. Está el repositorio de NX para código abierto y plugins y similares. Está el repositorio de NX Cloud para infraestructura y código cerrado. Y luego está el repositorio de NX Console, que es de código abierto. Probablemente podría estar en el repositorio de NX Open Source, pero no es necesario. Tiene versiones independientes, diferentes equipos trabajan en él, así que está bien mantenerlo allí. Así que lo mismo se aplica para ti. Lo más probable es que puedas comenzar a adoptar monorepos de manera incremental, agrupar lo que tenga sentido para ti, y no dejes que nadie más te diga cómo organizar tu código.

Hola. Así que para esta siguiente sección sobre tooling, voy a usar NX como ejemplo. Pero hay muchas otras herramientas de monorepo por ahí, y te animo a que vayas a monorepo.tools, que es un sitio web con información donde puedes aprender todo sobre monorepos y las herramientas para construirlos. Y todos esos autores de esas herramientas, colaboraron en el sitio. Así que es una comparación tan justa e imparcial como puede ser. Hola.

Bien. Así que voy a hacer una afirmación audaz, que es que ejecutar pruebas lleva tiempo. Bien, tal vez no sea la opinión tan candente que pensé que sería, pero es cierto, ¿verdad? Así que si ponemos más y más proyectos en nuestro monorepo, y hay más y más pruebas en nuestro monorepo, ¿no significa eso que el tiempo para probar, especialmente en CI, aumentará y aumentará y aumentará? Bueno, sí, pero también no, porque un buen tooling puede ayudar. Así que a través del análisis de tus importaciones, y tus archivos, y tu configuración, Enix puede construir este gráfico de proyecto de tu proyecto de tu espacio de trabajo. Puedes ver un ejemplo que me gusta usar aquí. Hay una aplicación de carrito y una aplicación de producto que probablemente trabajan juntas en alguna configuración de federación de módulos micro-frontend. Y hay algunas bibliotecas que comparten, y hay algunas bibliotecas que son solo para ellas. Así que a través de esto, en realidad se vuelve muy fácil para Enix ver qué está afectado por un cierto cambio. Bien. Así que hago un cambio en la página de detalles de productos, y Enix dirá que necesitaremos volver a probar, construir y lint, no, no lint, reconstruir y volver a probar la aplicación de productos, así como volver a ejecutar y probar la aplicación de productos para asegurarnos de que todo sigue funcionando. Pero no hay forma de que haya podido romper la aplicación de carrito porque no hay un camino en este gráfico desde la aplicación de carrito hasta la página de detalles del producto. Esto hace que CI sea mucho más simple también. En lugar de una larga lista de pasos, podemos simplemente decir, Enix, por favor vuelve a probar, lint, construir, ejecutar y probar todo lo que esté afectado por este cambio. Eso es todo. Esa es tu configuración de CI ahora.

Con esto, hemos desvinculado efectivamente el tiempo que lleva ejecutar tus pruebas, ejecutar CI, del tamaño de tu monorepo. Y en su lugar, lo hemos vinculado al tamaño del cambio que estás haciendo. Así que si estás haciendo un gran cambio que afecta a muchos proyectos en el monorepo, tu CI va a tardar más. Pero si haces solo un pequeño cambio que afecta solo a un pequeño subconjunto de proyectos, será muy rápido, sin importar cuán grande sea el resto del repositorio.

Entonces, ¿cómo más podemos hacer esto más rápido? Digamos que queremos ejecutar una compilación usando npm run build-dash-dashproduction. Hay muchas cosas que intervienen en definir cuál será la salida de esa compilación, ¿verdad? Archivos fuente, archivos de configuración, parámetros de 10S, como dash-dash production, dependencias generales. Y todos estos se toman juntos, se realiza algún cálculo y obtenemos una salida. En este caso, un archivo HTML en el paquete de JavaScript.

Así que Nx añade una caché de computación a esto. Y cómo funciona es así. Cuando ejecutamos la compilación, calculamos un hash. Y luego ponemos ese hash junto con las salidas en la caché de computación. Pero la próxima vez que quiera ejecutar la compilación, primero puedo calcular el hash, lo cual es muy barato. Y luego, si existe en la caché, puedo simplemente recuperarlo, lo que significa que mi compilación pasa de minutos a milisegundos. Y lo increíble es que esta caché puede ser compartida en toda tu organización. Así que en una gran organización, alguien siempre está trabajando, ¿verdad? Ya sea tu colega al otro lado del mundo, o tu pipeline de CI ejecutando pruebas nocturnas. Eso significa que si me desconecto por la mañana, y quiero ejecutar mi compilación, lo más probable es que alguien ya lo haya hecho por mí. Así que puedo simplemente recuperar de la caché, comenzar mi día de inmediato. Y esto es realmente poderoso porque significa que en ese Xmonorepo, con la caché de computación compartida, nunca se hace el trabajo dos veces. Nunca. Nunca. Nunca. Eso explica por qué es tan importante estructurar las cosas en bibliotecas también. No son solo tu unidad fundamental de arquitectura, también están ahí para permitir que Nx tome decisiones mucho más granulares cuando se trata de hacer cálculos efectivos o hashing. Nunca. Nunca. Nunca.

Así que en el peor de los casos, ya hemos podido eliminar, no lo siento, en el caso promedio, ya hemos podido eliminar mucho trabajo solo haciendo lo necesario con el hecho de que y almacenando en caché siempre que sea posible. Pero siempre habrá el peor de los casos donde hacemos un cambio en algún lugar profundo en el gráfico del proyecto que afecta a una gran parte del Mondorepo, o incluso a todo él. Y necesitamos algunas técnicas y algunas herramientas para asegurarnos de que nuestros tiempos de CI y todo siga siendo razonable. Ese es el caso. Si hago un cambio central y CI tarda tres días, eso es irrazonable, y la gente no puede trabajar con eso.

Entonces, ¿cómo hacemos eso? A través de este gráfico del proyecto, un X también puede generar un gráfico de tareas. Aquí hay un ejemplo de nuestra extensión de VS Code. Puedes ver que para construirlo, primero necesitamos construir la UI generada, necesitamos construir el servidor de lenguaje, y luego combinamos todo eso y construimos la extensión de VS Code en sí misma. Y con este gráfico de tareas, un X realmente puede hacer optimizaciones inteligentes al construir esto. Sabemos qué podemos paralelizar, sabemos en qué orden se deben ejecutar las cosas, y luego podemos programar todos esos trabajos antes de finalmente construir la extensión de VS Code en sí misma. Como puedes ver, esto ya es mucho más rápido que si simplemente ejecutáramos todo secuencialmente, ¿verdad? Pero hay un límite a lo que la paralelización puede hacer. Los flujos de trabajo tienen un número limitado de núcleos, no es una opinión controvertida de mi parte, y si comenzamos a paralelizar más y más cosas y ejecutarlas juntas, eventualmente comenzará a ralentizarse y hay un límite a la cantidad de trabajo que podemos hacer.

Así que necesitamos una manera de dividir estas cosas en múltiples agentes, distribuirlas. Así que hacemos eso. Tomemos nuestro ejemplo nuevamente, ejecutando build, lint, test, y pruebas netainn para todo. Está afectado en nuestro cambio. Y si es un cambio bastante grande, eso podría ser muchas tareas que necesitan ser ejecutadas. Así que una forma ingenua de dividir esto sería decir, construyamos cosas en un agente, probemos cosas en otro agente, etc. Pero esto es realmente ineficiente porque como puedes ver, mientras el agente tres está construyendo y construyendo y construyendo, los otros agentes solo están inactivos, desperdiciando dinero, tiempo, recursos. Y hay otra razón por la que esto realmente no funciona. Recuerda el gráfico de tareas, ¿verdad? Estos tienen dependencias entre sí.

Así que, por ejemplo, para construir las pruebas de extremo a extremo, necesito primero, para ejecutar las pruebas de extremo a extremo, necesito primero construir en esa misma máquina porque las pruebas de extremo a extremo necesitan construir artefactos de salida de esa máquina. Así que de repente hemos creado este problema realmente complejo donde necesitamos asegurarnos de que las cosas estén en el orden correcto mientras también respetamos esas dependencias de salida, en qué máquinas deben ejecutarse, mientras también tratamos de asegurarnos de que todo se ejecute de la manera más eficiente posible y ahorre tiempo.

Bueno, NX simplemente resuelve esa complejidad por ti. Puedes decirle, por favor distribuye todas estas tareas entre cuatro agentes y lo hará por ti. Porque tenemos el gráfico de tareas, sabemos en qué orden deben ejecutarse las cosas. Y porque tenemos la caché de computación distribuida, podemos desestimar completamente esa otra limitación de decir que las pruebas de extremo a extremo deben construirse y ejecutarse en la misma máquina que la compilación. El agente uno puede ejecutar las pruebas de extremo a extremo y cuando llegue el momento, puede simplemente reproducir la compilación desde la caché aunque se haya ejecutado en el agente cuatro. Y te permite saber la diferencia si se ejecutó en sí mismo o en otra máquina. Esto es realmente poderoso. Y porque es tan simple de configurar, puedes empezar a experimentar con ello. Puedes decir, tal vez quiero ahorrar un poco más de tiempo. Usemos seis agentes. Ajusto un solo número en la parte superior y mi tiempo de CI disminuye. O tal vez estás diciendo, esto en realidad no es tan crítico en cuanto al tiempo. Puedo esperar un poco más y ahorrar algo de dinero. Solo uso dos agentes. Y hoy en día, hay un modelo que construimos donde toma tu cambio. Puedes especificar el número objetivo de minutos que quieres que tu CI se ejecute. Puedes decir, quiero que mi CI tome 25 minutos. Entonces NX determinará para un cierto cambio cuántos agentes va a necesitar. Y esto es algo que no vas a poder evitar a cierta escala. Si tienes un gran monorepo, siempre habrá esos peores casos cuando tengas que volver a probar todo. Y si tienes que esperar tres días para que eso se haga, entonces simplemente no es factible.

Así que después de aprender todo esto, Dan está feliz. Puedes ver que se ve contento. Se ve enfocado en su trabajo. No está bebiendo por una vez, que es lo que realmente lo hemos visto hacer. Y si quieres estar enfocado y contento como Dan y conseguir esa línea de mandíbula también, tal vez, te recomiendo que vayas a monorepo.tools para aprender todo sobre monorepos. O puedes simplemente confiar en mi opinión imparcial e ir a nx.dev y leer nuestra documentación. Así que ahora que Dan está feliz, eso significa que yo estoy feliz. Y espero que todos ustedes hayan aprendido algo. Y ahora todo lo que queda por decir es gracias.