Y con el monorepo, puedes hacer el cambio, hacer todas las correcciones de una vez y se actualizan todos los micro frontends, ¿verdad? Así que en realidad te has deshecho de ese gran obstáculo de trabajar en estos micro frontends al ponerlos en el mismo lugar. Y tengo una publicación en el blog al respecto. Así que puedes ver como los micro frontends de React son una combinación perfecta con los monorepos.
De acuerdo, sí. Así que una pregunta que veo aquí, la reformularé un poco para no señalar a nadie, pero si tienes un equipo donde el patrón ha sido crear un nuevo repositorio para cada cosa pequeña, ¿cuál es tu recomendación para ayudar a los equipos a trabajar dentro del marco de NX Monorepo cuando ese ha sido el patrón anterior de dividir todo en pequeñas bases de código? Sí, y supongo que a medida que divides el código en pequeñas bases de código, también las publicas en un registro en algún lugar para que las personas puedan descargarlas. Creo que lo primero que haría es mover las partes publicables a NX y luego tener los diferentes proyectos dentro de NX y puedes ver las relaciones entre ellos, pero luego puedes publicarlos de nuevo, ya sabes, en artifactory, o cualquier otro registro, y luego puedes comenzar a incorporarlos desde nodos más altos de tu gráfico de dependencias.
Mm-hmm. Entonces, una pregunta que tengo es ¿cuál es la diferencia entre algo como NX y otras herramientas de gestión de monorepos como Lerna? ¿Son lo mismo o resuelven problemas diferentes? Sí, Lerna es muy popular y es realmente bueno, creo, para la gestión de paquetes. Entonces, NX tiene muchos paquetes diferentes que gestionamos y no usamos Lerna, pero sería bueno tener algo que simplemente ejecute todo, y eso es lo que hace Lerna. Te permite tener proyectos separados, pero te permite ejecutar compilaciones en todos ellos, probarlos a todos. Pero al final de mi charla estaba hablando de cómo, ya sabes, ejecutar todo llevará mucho tiempo una vez que llegues a la escala de cinco o seis equipos diferentes. Entonces, cuando hablas de organizaciones como Facebook, ejecutar todas las pruebas lleva mucho tiempo. Así que NX tiene la inteligencia, junto con eso, para poder ejecutar solo una parte de tus proyectos cuando sea necesario para verificar que el cambio sea seguro para la producción.
Entendido. Entonces, eso se relaciona con otra pregunta aquí, que es cómo se admite a los equipos grandes que trabajan en un solo repositorio si se necesita algo como una cola de fusión. Puede que no esté tan familiarizado con el término de cola de fusión, pero tal vez sea como, ya sabes, muchas personas trabajando en el mismo monorepo, podrías imaginar muchos conflictos de fusión, ¿verdad? Creo que también es una idea equivocada porque los conflictos de fusión solo ocurren cuando dos personas trabajan en lo mismo. Y no es exactamente como, ya sabes, mil personas trabajando en el mismo fragmento de código, ¿verdad? Todos están trabajando en su pequeña parte del monorepo. Así que muchas veces no tendrás conflictos de fusión, ¿verdad?, porque estás trabajando en algo completamente diferente a otras personas. Lo único es cuando estás trabajando en un cambio que afecta a todo el monorepo, digamos, como cambiar algo muy importante, entonces sí, habrá conflictos de fusión cuando las personas fusionen su código. Pero bueno, solo tendrás que hacerlo una vez en lugar de hacerlo 50 veces diferentes en todos esos equipos diferentes. Entonces, al final del día, sigue siendo más eficiente desde el punto de vista del flujo de trabajo, ¿verdad?, y sí, la única otra recomendación que tengo es que tal vez necesites esto, ya sabes, necesito este cambio, déjame simplemente forzarlo sin obtener todas mis aprobaciones o como, hay un equipo separado que maneja ese tipo de cambio. Así es como recomendaría hacerlo. No estoy seguro si entendí correctamente la cola de fusión. Entonces, la pregunta ha sido reformulada para hablar sobre una cola de implementación. Y bueno, voy a hablar sobre mi propia experiencia porque sé con certeza lo que estoy preguntando, solo para asegurarme. Y lo que he visto es que en muchas empresas, cuando estás listo para implementar algo en particular, digamos que el frontend de la aplicación está a punto de implementar algo. Puede haber múltiples ramas en marcha, pero bloquearán la implementación durante un período de tiempo para asegurarse de que el código se fusione y se implemente correctamente. El flujo de trabajo que usamos ahora no funcionaría en un monorepo porque estaríamos bloqueando a toda la empresa. La mayoría de ese código no se ve afectado por la implementación del frontend. Entonces, ¿cómo funciona un flujo de trabajo así, donde necesito decir, nadie puede fusionar en la interfaz de usuario durante este período de tiempo, cómo funcionaría eso? Sí, el flujo de trabajo de desarrollo que funciona muy bien con monorepos es un desarrollo basado en tronco. Eso significa que todos desarrollan en función de la rama principal o de desarrollo, pero todos los commits van allí.
Comments