El Multiplicador de Monorepo: 10x Tu Equipo con Mejor Arquitectura

Para darles una idea, estoy dando una charla después de 18 meses. Decidí tomarme un descanso, enfocarme más en mi salud y familia. Buenas noticias, estoy 15 kg más ligero, así que todo salió bien. Así que estoy aquí para hablar sobre monorepos.

Así que solo una pregunta. Pregunta rápida. ¿Cuántos de ustedes están usando monorepos? Bien, muchas manos. Bien. ¿Y cuántos quieren usar monorepos? Bien, solo uno. Bien. Espero poder cambiar la percepción porque los monorepos tienen muy mala fama cuando se trata de grandes bases de código, ¿verdad? Pero aún así Google lo hace. Y no hablaré de eso.

Así que hablemos de por qué prefiero los monorepos, ¿verdad? Así que mi viaje en monorepos comenzó hace seis años. Fue un cliente quien me preguntó, dice, oye, sabes, tenemos una aplicación y es una aplicación muy exitosa. Creo que realmente podemos replicar este negocio para muchos otros clientes y ganar más dinero. Y yo estaba como, bien, ¿qué necesitas? Entonces dijeron, sabes, tenemos un sistema de diseño. Si realmente podemos replicar esto, será más fácil para nosotros construir nuevas aplicaciones y podemos ir a un nuevo cliente y entregarlas más rápido. Como si tuviéramos una nueva aplicación lista para un nuevo cliente en una semana. Yo estaba como, bien, hagámoslo. Y fue entonces cuando decidí, lo siento, lo siento, ve 18 meses. Así que fue entonces cuando decidí, bien, exploremos los monorepos. Y encontré una herramienta que funcionó para mí. Y luego pensé, bien, esa fue la parte más fácil.

Dos años después, no dos años, pero sí, cuatro años, cerca de dos años después, fui contratado por una empresa llamada Silones. Tenían una base de código muy grande, pero dispersa. Así que esto es lo que estaban haciendo. Solo estoy diciendo cuatro aplicaciones, pero tenían como 30 aplicaciones, 30 aplicaciones, 30 repositorios, 30 diferentes equipos haciendo lo mismo. Y mi trabajo era, yo era realmente responsable de trabajar con todos. Y mi trabajo era realmente hacer esto, como clonar cada monorepo, perdón, clonar cada repo, instalar módulos de nodo, ver los cambios que rompen, actualizar todas las aplicaciones.

Si estoy actualizando el sistema de diseño, tengo que ir a todas partes y ver quién tiene la capacidad de actualizar el sistema de diseño, y fue un infierno. Todos sabían que estábamos lanzando lentamente. Recuerdo cuando me uní a ellos, nos tomó un mes sacar una pequeña versión porque tan pronto como comenzamos, ya sabes, a actualizar nuestra versión de Angular, comenzamos a romper todo. La mayoría de los equipos estaban luchando.

Ellos decían, está bien, incluso el rollback era un problema porque ¿cómo debería saber cuál está fallando? Porque sabes lo que estábamos haciendo? Solíamos cargar 30 aplicaciones diferentes dentro de un micro frontend. Y era nuestra propia solución personalizada. Así que todo era un lío allí.

Así que como, está bien, veamos qué podemos hacer. Así que este era nuestro sistema antiguo, ¿verdad? ¿Cuántos de ustedes conocen los polyrepos? Creo que todos, ¿verdad? No tengo que hacer esta pregunta. Todos lo están usando. Quiero decir, lo hemos estado usando durante años, ¿verdad? Polyrepos. Así que lo que hacemos, realmente trabajamos así.

Así que tienes un sistema de diseño cambiante, construyes, pruebas, publicas, luego actualizas la versión a app uno, app dos, app tres, app cuatro. Y luego el ciclo continúa. Haces PR, revisas, fusionas, y luego sigues adelante. Si tienes suerte, hay múltiples equipos haciéndolo. Si no tienes suerte, eres el único responsable de todo. Luego, el otro costo es para 30 aplicaciones, a veces sucede que 10 equipos están listos para actualizar. 10 equipos no están listos para actualizar. Entonces, ¿qué haces?

Y decir, está bien, te apoyaremos, 10 chicos. 10 chicos, pueden seguir adelante. Y así es como entras en el infierno de dependencias. Y no hay vuelta atrás desde allí. Así que un gran concepto erróneo cuando se trata de monorepos, o al hablar de proyectos es, la mayoría de la gente piensa un repositorio es un proyecto. Porque así es como creo que todo comenzó, ¿verdad? En los días antiguos, teníamos java.net. Y todo era un repositorio, un proyecto. Y luego llegaron los microservicios, la gente comenzó a dividir sus aplicaciones, y luego se dieron cuenta, ¿por qué deberíamos tener microfrontend o microservicios? Y luego fue una mala práctica de nuevo. Así que en realidad, lo que puede suceder es que un proyecto puede abarcar múltiples repositorios, eso es polyrepo. Y un repositorio puede contener múltiples proyectos, eso es monorepo. Así que veamos. Diagrama simple para mostrarte monorepo, polyrepo y monolito. Estoy seguro, al mirarlos a todos, estoy seguro de que la mayoría de ustedes podría haber usado monolitos. Creo que ahí es donde comenzamos, ¿verdad? .NET, Java, monolito único, desplegamos todo junto. Así que veamos cómo se ven los monorepos.

Así que en monorepo, lo que haces es que tienes múltiples aplicaciones. Puedes compartir el código. Por ejemplo, sistema de diseño en este caso. Y todos tienen la misma versión. Así que no es como múltiples versiones, no hay infierno de dependencias, no hay gestión de múltiples versiones. Puedes simplemente tener la misma base de código en todos los entornos, fácil de arreglar, fácil de avanzar adelante. En polyrepo, tendrás tus repositorios o proyectos, o parte de los proyectos, dispersos a través de múltiples repositorios. Aquí es donde entra en juego el infierno de dependencias. ¿Cuándo deberías usar monorepo? Diré siempre. Quiero decir, eso es lo que pienso. Y después de trabajar durante tantos años en el espacio de monorepo, creo que siempre deberías seguir adelante y recomendar monorepo a cualquiera. Pero te daré algunos puntos de lo que es el mejor caso de uso, ¿verdad?, cuándo deberías estar usando monorepos. El primero es, por supuesto, cuando tienes múltiples proyectos compartiendo dependencias de código. Y estoy seguro de que en el mundo de hoy, es muy común hacer esto.

Muchos proyectos en realidad interdependen entre sí dentro de la organización. Así que un ejemplo común es tu sistema de diseño. No sé cuándo comenzó esta tendencia, pero en algún momento, cada empresa quería su propio sistema de diseño. Decían, no, no voy a usar tal vez ShadC y UI, o tal vez Material UI. Construiremos el nuestro porque somos únicos. No sé quién es único. Y luego bibliotecas compartidas, ¿verdad? Tienes algún código que en realidad se comparte entre múltiples proyectos, y dices, oh, ¿dónde debería poner este código? Así que está bien, creemos una biblioteca compartida. Y lo ponemos allí. Necesidad de cambios atómicos. Creo que esta es una de las cosas con las que en Selonis estábamos luchando mucho. Solíamos hacer cambios en una pequeña biblioteca, actualizarla en 30 lugares, y ahora dos aplicaciones se rompieron. Así que nuestros commits en realidad se han dispersado ahora en 32 bibliotecas diferentes, o 32 bases de código diferentes. Así que con monorepos, en realidad no ves esto. Tienes en realidad un cambio disruptivo, un solo commit, ¿verdad? Porque lo que estás cambiando, y en realidad actualizas todo el monorepo con el mismo cambio. Por ejemplo, un simple cambio de API, ¿verdad? Agregaste un nuevo parámetro. Solo piensa en ir a 30 bases de código solo para actualizar un parámetro, y estar en un monorepo donde sabes, oh, si hago algo, mi build se romperá de todos modos. Y actualizaciones de API también. Así que estos son múltiples casos donde obtienes la ventaja de cambios atómicos.

Así que todavía tengo 10 minutos, así que iré un poco más rápido. Y refactorización a gran escala. Un ejemplo simple puede ser actualizar tu versión de React, ¿verdad? Así que si tienes múltiples proyectos con múltiples o diferentes versiones de React, y hay un cambio disruptivo, se convierte en un dolor en realidad actualizarlos. Créeme, la gente en realidad deja las empresas para cuando terminan todas las migraciones. Pero en monorepos, en realidad puedes hacerlo en una sola actualización, ¿verdad? Y luego, fuerte cultura de reutilización de código. Dejamos de reinventar la rueda, porque todos están usando la misma base de código, así que todos saben lo que está pasando. Y productos interconectados, por ejemplo, micro frontend y backends compartidos. Este es también un caso de uso donde en realidad puedes simplemente seguir adelante y usar monorepos. ¿Por qué el equipo ama el monorepo? Quiero decir, en Selonis, comenzamos desde cero. Así que comenzamos, como, incorporando, hablando con los equipos, y luego comenzamos a incorporarlos a todos. Inicialmente, eran resistentes, como cualquiera lo sería. Pero una vez que vieron, como, ahora estamos compartiendo más código, y tenemos más código reutilizable, dijeron, como, está bien, eso está absolutamente bien.

Esto es lo que amamos. Commits atómicos. Comenzaron a amarlo porque ahora pueden rastrear los cambios o cambios disruptivos a un solo commit. No tienen que ir a través de 30 repositorios diferentes para hacer esto.

Dependencias simplificadas. Ahora, no tengo que clonar 30 repositorios diferentes para averiguar qué bibliotecas actualizar o qué paquetes actualizar. Puedo hacerlo en un monorepo. Muchas herramientas soportan un solo archivo JSON de paquete. Así que ni siquiera tienes que mantener múltiples archivos package.json. Solo depende de las herramientas que estés usando.

CI-CD unificado. Así que esto es algo realmente asombroso, porque, ya sabes, 30 diferentes pipelines de CI-CD contra un solo pipeline de CI-CD, estoy seguro de que la gente solo recomendará uno, ¿verdad? Y mejor colaboración. Comenzamos a trabajar como un equipo. Así que en algún momento, teníamos, como, 400 colaboradores en el monorepo, y todos vivían felices para siempre.

Este es un ejemplo de nuestra base de código una vez que nos movimos a monorepo. Teníamos una base de código heredada. Estoy seguro de que las bases de código heredadas existen en todas partes. Y esta base de código heredada era un vertedero para todos los equipos. Necesitas una nueva función. ¿Dónde debería ir? Así que esta función reutilizable. Así que esta biblioteca reutilizable. Y en algún momento, esta biblioteca reutilizable, que era de 800 KB, se multiplicó por 30 proyectos. Así que 800 KB por 30. Eso es como la cantidad de código que estábamos enviando. Tan pronto como nos movimos a monorepo, eliminamos el 98% del código. Desaparecido. Quedaron 4 KB de código. Así de fuerte es la cultura de reutilización de monorepo.

Entonces, cuando hablo de cambios atómicos, a qué me refiero con cambios atómicos. Así es como se ve. Por ejemplo, si tienes múltiples proyectos, lo que harás es ir y actualizar el mismo código en múltiples repositorios. Múltiples commits volarán a través de tu organización. Pero en commits atómicos, tienes un solo commit identificando qué cambió, por qué lo cambiaste y necesitas rastrearlo cuando algo sale mal. Este es un ejemplo simple. ¿Verdad? Por ejemplo, solo actualicé un solo parámetro. El ejemplo ya te lo di. Con monorepo, puedes detectar esto temprano, en lugar de publicar y luego descubrir que algo está roto para esta aplicación, porque nos perdimos un parámetro. Lo cual es un caso muy normal. Caso normal, muy fácil de usar. Dependencias simplificadas.

Ahora tienes todos los proyectos usando la misma versión de React. No tienes el infierno de versiones de dependencias, que generalmente tenemos, en caso de que estemos usando múltiples versiones de React o múltiples versiones de Angular o lo que sea. ¿CICD unificado? Nuestro CICD comenzó a parecer un trabajo hecho por expertos en lugar de un desastre.

Entonces, antes teníamos 30 diferentes canalizaciones CICD, cada una empujando su base de código a una base de datos, luego la recuperaban, la mostraban en Microfrontend, y ahora simplemente nos movimos a una única canalización CICD donde sabemos qué proyectos construir, qué proyectos ejecutarán Linter, qué proyectos ejecutarán los casos de prueba de extremo a extremo, qué proyectos ejecutarán casos de prueba unitarios. Podemos averiguar qué proyectos ejecutar, incluso en ese caso. Por ejemplo, digamos una biblioteca compartida. Si cambio la biblioteca compartida y la nueva función no está siendo utilizada por mis 29 proyectos, aún necesito construir esos 30 proyectos cada vez. En este caso, solo estábamos construyendo uno. Solo una vez. Sin tocar esos 29 proyectos. Y todo depende de las herramientas, para ser franco.

Y todos ven todo, ¿verdad? Solo piensa en un nuevo ingeniero junior que se une a tu empresa y ve, oye, todo el código está disponible. De hecho, puedo ir y ver qué está haciendo mi superior. Él es un ingeniero de back-end y tal vez quiero aprender de él. Y puede simplemente ir y ver la base de código, cómo un ingeniero senior ha estado escribiendo código o cómo un ingeniero principal está escribiendo un código. Fácil de descubrir bases de código, fácil aprendizaje de las mejores prácticas. Porque una cosa cuando trabajas en un equipo es que traes muchas ideas diferentes. Cuando trabajas en un monorepo, estás compartiendo esas ideas. Y así es como realmente estás ayudando a tus colegas a tener éxito. Estas son las prácticas estándar. Puedes trabajar como un equipo, discutir y llevar tu monorepo a algo nuevo o hacerlo más saludable.

Y colaboración entre equipos. Esto es lo que comenzamos a ver. Después de que comenzamos a trabajar con 40 equipos diferentes, los equipos comenzaron a hablar entre sí. No es como, no, no somos enemigos, en realidad somos amigos. Queremos lograr lo mismo. Si estamos trabajando en la misma función, ¿por qué deberíamos hacerlo de manera diferente? Trabajemos juntos y averigüemos cuál es la mejor solución. Y también puedes identificar a tus principales contribuyentes. Sabes, cuando tienes repositorios en 30 repositorios diferentes, no sabes quién está contribuyendo más. Pero con monorepos, sabes que el principal contribuyente es IA. Solo bromeo. Así que, rápidamente iré con la ventaja de IA porque todos quieren saber qué está cambiando la IA. Así que, ahora, según los estudios recientes, de hecho, más del 25 al 40% del código está siendo escrito por IA.

Creo que no podemos negar el hecho, porque he escrito código a mano la última vez, hace siete meses. Así que sé que he estado usando principalmente IA. Pero la IA necesita contexto. Todos lo saben. Aunque, sí, a veces estamos confundidos, como, qué es el contexto. Pero necesita contexto. Necesita algo. E incluso los nuevos softwares, si piensas en cualquier nueva biblioteca, por ejemplo, piensa en Angular o React, en realidad no están creando nuevas APIs para humanos. Están creando nuevas APIs para agentes. Están diciendo que la era de la experiencia del desarrollador ha terminado. Ahora, es la era de la experiencia agéntica. Así que, tus agentes deberían conocer mejor el código. Tus agentes deberían poder entender las APIs. Y hacia allí vamos.

Y el cambio de contexto sigue siendo un problema. Si estás trabajando en un polyrepo, así es como se ve tu día. Entonces, comienzas a las 9 a.m., arreglas un error en el repositorio de front-end, clonas npm install, lo que sea, actualizas API en tu backend, diferente versión de node, diferentes herramientas, luego vas al sistema de diseño, herramienta de construcción, diferentes scripts. Y luego a las 3 p.m., tienes tu repositorio de aplicación móvil, donde vas y haces algo. Y a las 5 p.m., te preguntas, como, qué estaba haciendo, en realidad. Y luego te vas por el día. Así que, tu día ha terminado, no hiciste nada, si estás trabajando en un polyrepo. Y en realidad, este es el costo oculto del cambio de contexto. Necesitas al menos 23 minutos. Esto no soy yo, por supuesto. Esto es como una investigación realizada por expertos que dicen que si estás cambiando entre múltiples trabajos, necesitas al menos 23 minutos. Estoy seguro de que necesito más de 30 minutos.

Así que, los desarrolladores cambian de repositorios de 5 a 10 veces al día. Esto es muy común en grandes organizaciones. Y el tiempo que estás perdiendo es de 2 a 4 horas diarias. Y luego la carga mental es que tienes que estar al tanto de diferentes comandos, porque npm, yarn npm, o npm, tienen diferentes comandos, diferentes entornos, diferentes flujos de trabajo CICD, porque tienes que estar al tanto, oh, ¿cómo se supone que debo ejecutar el linting aquí de nuevo? Y luego estás perdido.

Diferentes estándares de codificación, lo que está causando mucho trabajo adicional para diferentes equipos. Porque cuando realmente mueves a un ingeniero junior a diferentes equipos, el mayor problema es enseñarles de nuevo. Porque diferentes equipos dicen, oye, no hacemos esto aquí.

Estamos siguiendo diferentes estándares de codificación. Y él está como, ¿qué demonios estamos haciendo? Así que, el costo anual es de 50K por desarrollador perdido en productividad, trabajando en un polyrepo. El mayor desafío de la IA es el contexto.

Así que, tu IA no puede ver tu contrato de API de backend. No puede ver tu implementación de biblioteca compartida. No puede ver tus problemas anteriores, cómo estás resolviendo los problemas.

Ahora puedes decir, oh, solo le pedí a mi IA, adelante y consulta este repositorio, hace un buen trabajo. Pero estás desbordando tu ventana de contexto. No está ayudando. En realidad, solo está golpeando tu ventana de contexto. Con monorepo, tu IA obtiene la imagen completa. Conoce tu implementación de API. Sabe qué lenguaje estás usando para tu backend. Conoce tus patrones de API de biblioteca compartida. Sabe cómo otros equipos están resolviendo este problema. Y tiene acceso a todo tu gráfico de dependencias.

Ahora, las últimas herramientas son, ya sabes, con arneses, es fácil para la IA ir adelante y incluso averiguar tu gráfico de dependencias. Sabe cómo puedo escribir nuevo código de una mejor manera. Porque conoce tu gráfico de dependencias. Y entiende tu lógica de negocio de frontend a backend. Porque la IA no es tu ingeniero full stack normal. Conoce todos los lenguajes. No se restringe solo a un node o C sharp o Java. Puede escribir código en cualquier lenguaje. Y si te mueves a IA, perdón, monorepo hoy, en realidad estás mejorando mucho tus agentes de IA al darles estas sugerencias contextuales profundas y precisas.

Así que el contexto es lo que necesitamos. Ejemplo simple, por ejemplo, tienes una API llamando desde tu frontend. Pero en realidad, esto es de nuestro caso de uso real donde intentamos llamar a una API. En monorepo, nos dimos cuenta, Oh, esta API está realmente obsoleta. La estábamos documentando. Se suponía que debíamos ponerla en producción. Pero nos dimos cuenta, está bien, esto está obsoleto, por qué lo estamos usando. Así que ejemplo simple, la IA también puede ver tus cambios disruptivos a través de. Así que puede decirte que algo podría romperse si haces algo, porque tiene una visión general de tu base de código. Y la IA puede aprender de tu organización. Estoy 10 minutos tarde.

Pero creo que, sí. Y la IA puede volverse realmente 10 veces más precisa. Si le das una imagen completa, significa entender mejor tu base de código, aprender de errores pasados, porque conoce tus commits pasados, decisiones pasadas que has tomado, el mejor conocimiento práctico o mejores prácticas sobre tu base de código, y conoce tus dependencias. Así que está al tanto de todo. Y también es fácil de analizar, ¿verdad? Si quieres seguir adelante y preguntar, como, oh, estoy planeando hacer esto, dame toda la imagen, como cómo se verá desde el frontend hasta el backend, puede hacer eso por ti. Así que solo detendré mi charla aquí, porque estoy excediendo el tiempo. Pero en caso de que tengas alguna pregunta, podemos realmente tomarla. No estoy hablando específicamente de herramientas, porque hay muchas herramientas disponibles. Si quieres discutir sobre alguna herramienta, estoy feliz de hablar sobre eso más tarde. Pero sí, detendré mi charla aquí. Gracias. Gracias. Muchas gracias.

Sí, así que básicamente, continuemos donde más o menos acabas de detener tu sesión. Todo se trata de contexto, ¿verdad? Sobre el uso de IA en PolyRepo o Monorepo. Y creo que hay dos preguntas muy similares. Básicamente, preguntas o preocupaciones. Mencionaste solo las partes buenas de tener Monorepo en el contexto de IA, ¿verdad? Pero siempre hay pros y contras, ¿verdad? Y el contexto es extremadamente costoso hoy en día. Así que con más contexto, tienes más tokens, definitivamente más conocimiento. ¿Y cuáles podrían ser algunas cosas a tener en cuenta cuando específicamente construyes tu capa de contexto en un gran Monorepo? Cuéntanos. Así que hay múltiples maneras de hacerlo. Así que tienes todas las herramientas de IA, tienen su propio archivo de instrucciones. Esa es la mejor manera. Realmente vas y haces eso. Puedes definir tus instrucciones basadas en tus proyectos de Monorepo también. Así que no necesitas limitarte. Di, OK, solo pondré todo en agents.md. Puedes ir a tus proyectos y poner un archivo allí. Los agentes saben cómo leer esos archivos. Así que esa es la mejor manera de hacerlo.

Divide tus instrucciones en diferentes partes del Monorepo. Creo que cada asistente de código importante está apoyando algo así. Así que quiero decir, no cargues todo de una vez. Sí, exactamente. O tu recomendación principal. Sí.

Gracias. Y la siguiente pregunta que realmente resuena, mirando el número de personas que... Espera, lo siento. Oh, creo que hice clic en el botón equivocado. Déjame intentar encontrar eso. Pero de todos modos, recuerdo, recuerdo la pregunta. La pregunta era sobre en un gran Monorepo, podría haber diferentes partes de tu proyecto que requieren diferentes permisos, diferentes reglas de cumplimiento. ¿Cómo manejas esa complejidad? Quiero decir, para dar el acceso, por ejemplo, el archivo Code Honest es muy útil. Como sabes qué parte del proyecto es propiedad de... Creo que se trata de propiedad, ¿verdad? Y Code Honest hace un muy buen trabajo. Sé que no es una herramienta perfecta.

Quiero decir, la tuvimos y aún estábamos luchando con ella. Creo que GitHub aún puede hacerlo mejor. Si tienes recomendaciones, creo que cuando trabajaba en Solanus, dimos muchas recomendaciones para mejorar Code Honest. Pero si tienes recomendaciones, simplemente adelante y habla con GitHub. Espero que lo mejoren. Aparte de eso, las herramientas pueden hacer un mejor trabajo. Por ejemplo, NX o TurboRepo, te ayudan a identificar qué proyectos han cambiado. Así que sabes, puedes construir tu propia herramienta personalizada sobre eso. He visto a muchos amigos haciendo esto con TurboRepo, porque TurboRepo te da webhooks. Así que, sabes, identificas, está bien, esta parte del proyecto ha cambiado. Y para este proyecto, estoy haciendo algo personalizado. Así que puedes ejecutar tus propios comandos.

Con NX, también, puedes hacer lo mismo. Genial. Así que, sí. Por cierto, también veo esto como una fuerte tendencia de que las empresas crean cada vez más herramientas internas. Y muchas de ellas también están de alguna manera relacionadas con AI. Y podemos llamar a esto tu capa de arnés externa sobre tu sistema de código genérico que principalmente usas. Sí, y las mismas preguntas sobre el contexto. Vamos a elegir esta. CI es extremadamente lento en Monorepo. Puede resolverse con la concurrencia adecuada, pero luego se vuelve costoso con cientos de cambios por día. ¿Cómo resuelves eso? Sí, entonces, sabes, tuvimos el mismo problema una vez que comenzamos a hacer crecer nuestro Monorepo en Selonis. Así que en algún momento, habíamos alcanzado 5 millones de líneas de código. Y teníamos 400 proyectos. Así que 400 proyectos, y teníamos como cientos de ERs por día. Así que decidimos ir con algo conocido como MergeQueue. Es en realidad una característica de GitHub. Puedes habilitarlo. Está disponible para empresas. Entonces, lo que hace MergeQueue es que puedes fusionar múltiples PRs a la vez. Entonces, sabes, lo que puedes hacer para PRs, cuando levantas un PR, puedes realmente ejecutar las tareas mínimas requeridas. Y cuando se promueven a MergeQueue, hacer el trabajo pesado allí. Por ejemplo, ejecutar tu prueba de extremo a extremo, que siempre es costosa. Y en MergeQueue, puedes definir el tamaño de la cola de 5 a 10. Creo que 10 es algo que se recomienda. Así que en ese caso, 10 PRs ejecutan esta prueba de extremo a extremo una vez, lo cual es mucho más rápido que realmente ejecutar 10 veces la prueba de extremo a extremo nuevamente. Entonces, MergeQueue, hay múltiples productos disponibles. Si no quieres seguir adelante, ir con MergeQueue. De GitHub, está Mergify. Y hay uno, trunk.io. Así que estas son dos herramientas o productos diferentes disponibles también.

Muchas gracias. Recomendaciones muy específicas y prácticas. Así que marquemos esto como respondido. Sí, creo que acabamos de revisar estos permisos. Contexto, de nuevo. Si tenemos tiempo, volveremos al contexto, pero veo que la siguiente pregunta resuena. Pongámoslo aquí.

En mi experiencia, nuestro monorepo con alrededor de 1.5 millones de líneas de código en el back-end y la mitad de eso en el front-end alcanza los límites de contexto muy rápido. De nuevo, volvemos al contexto. En ese caso, ¿podría funcionar mejor el polyrepo? Creo que me gustaría diferir aquí porque teníamos nuestro propio monorepo con 5 millones de líneas de código, y ni siquiera era back-end. Era todo el código del front-end, 5 millones de líneas de código, incluyendo nuestra prueba, prueba de extremo a extremo, prueba unitaria, y tu front-end. Y nunca tuvimos este problema porque en realidad, cuando comenzamos a usar AI, nos dimos cuenta, está bien, está causando que nuestros límites de contexto sean un problema. Y luego comenzamos a escribir instrucciones personalizadas para cada proyecto. Así que no está cargando todo a la vez. Solo está tomando en contexto lo que necesitamos o lo que el proyecto necesita. Así que esa es la mejor manera de proceder. Sé que este es el mayor problema. Así que hemos estado allí.

Sí, porque una de las preguntas era específicamente, ¿necesitamos de alguna manera reestructurar todo el proyecto? Lo más probable es que no, ¿verdad? Es solo la reestructuración de tus instrucciones a través de estos múltiples proyectos, ¿verdad? Eso es algo que necesitas resolver. Por ejemplo, NX te da algo conocido como gráfico de dependencias. Así que sabes cómo están relacionados los proyectos. Si tu gráfico de dependencias es un desastre, entonces lo primero que debes hacer es desenredar esas dependencias. Y luego tienes dependencias claras y adecuadas, y entonces tu AI hace un mejor trabajo porque sabe qué proyectos considerar realmente cuando estás haciendo cambios. Sí, suena como un gran consejo. Arregla las cosas básicas primero, y solo entonces piensa en qué arreglar para AI. Exactamente. Sí, creo que podemos marcar esto como leído.

Siguiente sobre contexto, pero vamos por este. ¿Cómo migrar mejor del complejo infierno de PolyRepo a un monorepositorio más simple sin reescribir todo desde cero? Muy bien. Buena pregunta, por cierto. Esto estaba en una de las diapositivas, pero decidí omitirlo. Pero muy buena pregunta porque lo hicimos. Así que lo que decidimos hacer es no realizar una migración de gran explosión. Así que todo está detenido y nadie puede enviar. Entonces lo que hicimos fue tomar algunos proyectos. Tomamos algunos proyectos, grandes proyectos, y dijimos, oye, lo estamos migrando para ti. Hagamos esto por ti. Así que porque eres un gran proyecto, otras personas tendrán más confianza en que funciona. Y luego comenzamos a hacer una migración incremental. Y nuevamente, depende totalmente de cómo planifiques tus migraciones. Así que tienes que asegurarte de que la antigua forma de trabajar no se detenga. Así que decidimos ir de esa manera. Dijimos, está bien, continuaremos con este, pero nos aseguraremos de que la antigua forma de enviar proyectos no se detenga en absoluto. Y luego, créeme, nos tomó más de un año. Así que no fue un trabajo de una semana. Teníamos 30 proyectos y tuvimos que salir y convencer, hablar con todos, solucionar sus problemas. Y nos tomó más de un año finalmente migrar todo. Por supuesto, el negocio no debe detenerse. Exactamente. Porque, sí, pienso en esta continuidad. Muchas gracias, mi amigo. Gracias. Muchas gracias.