polirepositorio<\/b><\/a> es un repositorio que contiene m\u00faltiples proyectos. <\/b>Us\u00e1bamos un estilo de organizaci\u00f3n de polirepositorio, lo que significa que cada proyecto de front-end ten\u00eda su propio repositorio, aunque muchos de los proyectos repet\u00edan las mismas tareas y reproduc\u00edan las mismas funciones. Como centro principal, los polirepositorios pueden convertirse en un desaf\u00edo de mantenimiento a medida que crece el n\u00famero de proyectos almacenados. En muchos casos, tuvimos que desplegar cada polirepositorio simult\u00e1neamente con las mismas actualizaciones para asegurar una experiencia coherente en todos nuestros productos.<\/p>\n\n\n\n Desde la perspectiva del mantenimiento, esto dificultaba que los equipos localizaran y trabajaran con el c\u00f3digo que necesitaban. Gestionar m\u00faltiples repositorios con caracter\u00edsticas redundantes suele significar que son m\u00e1s lentos en responder y<\/i> que consumen m\u00e1s recursos, lo cual es un gran problema si frecuentemente haces push y pull de c\u00f3digo. Como las funciones pueden distribuirse en m\u00faltiples bases de c\u00f3digo, los polirepositorios pueden hacer que encontrar errores sea m\u00e1s dif\u00edcil que encontrar la proverbial aguja en el pajar.<\/p>\n\n\n\n
Con nuestra estructura de polirepositorio previa a la reconstrucci\u00f3n, sab\u00edamos que el futuro ser\u00eda una realidad de buscar en los repositorios con una linterna para encontrar lo que necesit\u00e1bamos, y que ser\u00eda un desaf\u00edo colaborar, escalar y compartir c\u00f3digo a medida que crec\u00edamos.<\/p>\n\n\n\n
Estas eran nuestras principales preocupaciones:<\/b><\/p>\n\n\n\n\nCodesarrollo desafiante<\/li>\n\n\n\n Acoplamiento estrecho<\/li>\n\n\n\n Gesti\u00f3n de la escalabilidad, disponibilidad y rendimiento<\/li>\n\n\n\n Dificultad para compartir c\u00f3digo<\/li>\n\n\n\n Duplicaci\u00f3n<\/li>\n\n\n\n Herramientas inconsistentes<\/li>\n<\/ul>\n\n\n\nEn cuanto a la gesti\u00f3n del c\u00f3digo fuente, hay muchas soluciones, pero decidimos que una estructura modular de monorepositorio aliviar\u00eda la mayor\u00eda de nuestros problemas de desarrollo de cara al futuro.<\/p>\n\n\n\n
El plan para un repositorio nuevo y reluciente: Un enfoque modular<\/h2>\n\n\n\n Un enfoque de monorepositorio implica almacenar todo el c\u00f3digo del proyecto en un solo repositorio grande<\/b>. Esto resolver\u00eda los problemas de duplicaci\u00f3n y compartici\u00f3n de c\u00f3digo que experimentamos con nuestra organizaci\u00f3n de polirepositorio, pero los monorepositorios no son una soluci\u00f3n m\u00e1gica. Si el c\u00f3digo est\u00e1 estrechamente acoplado, los monorepositorios tambi\u00e9n deben dise\u00f1arse de forma modular.<\/p>\n\n\n\n
Un enfoque modular implica dividir un proyecto grande en m\u00f3dulos m\u00e1s peque\u00f1os e independientes que se pueden desarrollar, probar y mantener por separado<\/b>. Esto permite una mayor flexibilidad y reutilizaci\u00f3n, as\u00ed como la capacidad de actualizar f\u00e1cilmente los m\u00f3dulos individuales sin afectar al resto del proyecto.<\/p>\n\n\n\n
Sab\u00edamos que una soluci\u00f3n modular de monorepositorio nos permitir\u00eda ser m\u00e1s eficientes con:<\/p>\n\n\n\n
\nGeneraci\u00f3n de c\u00f3digo<\/li>\n\n\n\n Compartir c\u00f3digo<\/li>\n\n\n\n Ejecuci\u00f3n y orquestaci\u00f3n distribuida de tareas<\/li>\n\n\n\n Cach\u00e9<\/li>\n\n\n\n TypeScript<\/li>\n<\/ul>\n\n\n \r\n\r\n
TypeScript es un superconjunto tipado de JavaScript que facilita a los desarrolladores la creaci\u00f3n de proyectos a gran escala.<\/b> Mejora la experiencia del desarrollador al proporcionar interfaces, alias de tipo, an\u00e1lisis de c\u00f3digo est\u00e1tico en tiempo de desarrollo y otras herramientas, a la vez que permite a los desarrolladores a\u00f1adir tipado a sus proyectos. Para nuestro equipo, TypeScript es una habilidad que sab\u00edamos que quer\u00edamos empezar a buscar a la hora de a\u00f1adir miembros a nuestro equipo.<\/div>\r\n <\/div>\r\n\n\n\nPisando callos: El baile del despliegue<\/h2>\n\n\n\n Sin lugar a duda, el mayor desaf\u00edo de vivir en un monorepositorio (monol\u00edtico o no) es que cuantas m\u00e1s personas contribuyan, mayor ser\u00e1 la posibilidad de que nos pisemos los unos a los otros. \u00bfDe qu\u00e9 sirve una experiencia de desarrollo renovada si tu c\u00f3digo se sobrescribe en una mala fusi\u00f3n? Si realmente estamos haciendo una revisi\u00f3n integral de nuestro stack, tambi\u00e9n debemos estudiar c\u00f3mo podemos mejorar nuestro proceso de despliegue. Estos eran los retos m\u00e1s urgentes:<\/p>\n\n\n\n
\nEscalabilidad: <\/b>Ser\u00eda una mala idea reconstruir TODO el c\u00f3digo del monorepositorio para los cambios m\u00e1s peque\u00f1os, por ejemplo, corregir un error tipogr\u00e1fico en alg\u00fan texto. Eso es exactamente lo que hac\u00edamos en nuestro antiguo sistema. El nuevo proceso aprovechar\u00eda las capacidades integradas de NX para evaluar y reconstruir \u00fanicamente el archivo o archivos afectados por el cambio, en el nivel m\u00e1s granular.<\/li>\n\n\n\nDespliegue: <\/b>Mantuvimos la mayor parte de la estructura de nuestra canalizaci\u00f3n de despliegue. Una vez construida la imagen, aterriza en el repositorio de contenedores de GitHub. Nuestro equipo SRE puso a punto nuestro sistema de despliegue durante la migraci\u00f3n de AWS a GCP. Podemos desplegar f\u00e1cilmente cualquier rama desde nuestro canal de despliegue de Slack, con un mejor informe gracias a una incorporaci\u00f3n reciente que obtuvimos durante la migraci\u00f3n.<\/li>\n\n\n\nCI\/CD:<\/b> Nuestro antiguo sistema usaba una versi\u00f3n muy antigua de Jenkins para ejecutar pruebas y construir\/distribuir las im\u00e1genes de nuestra app tras una VPN. Cuando la compilaci\u00f3n fallaba, necesit\u00e1bamos que un desarrollador s\u00e9nior de alto nivel, familiarizado con las viejas costumbres, lo arreglara. En nuestro nuevo sistema, el plan era pasarnos a GitHub Actions, donde las configuraciones son accesibles, declarativas y est\u00e1n bien documentadas.<\/li>\n<\/ul>\n\n\n\nDesaf\u00edos absurdos y soluciones excelentes<\/h2>\n\n\n\n Los proyectos de cualquier tipo presentan desaf\u00edos, algunos esperados y otros sorprendentes. Sab\u00edamos que necesit\u00e1bamos un plan para superar algunos problemas y que la nueva versi\u00f3n de la app deb\u00eda centrarse en el rendimiento desde m\u00faltiples \u00e1ngulos.<\/p>\n\n\n\nProblemas identificados<\/th> Soluciones propuestas<\/th><\/tr><\/thead> Convenciones de c\u00f3digo poco claras<\/strong>Gu\u00eda de estilo de c\u00f3digo<\/strong>Estado sobrecargado<\/strong>Separaci\u00f3n de la cach\u00e9 de red y el estado de la aplicaci\u00f3n<\/strong>Arquitectura de red multicapa<\/strong>Las API p\u00fablicas primero<\/strong>No tires todo por la borda<\/h3>\n\n\n\n Hemos escrito cientos de miles de l\u00edneas de c\u00f3digo durante la \u00faltima d\u00e9cada. Con la escala y el alcance de este nuevo plan, se tardar\u00eda casi los mismos a\u00f1os en portar y reescribir nuestras funciones antiguas en el nuevo paradigma. Esto era inasumible. Necesit\u00e1bamos encontrar una forma de seguir incorporando estas funciones existentes sin comprometer nuestros objetivos para el nuevo stack. Encontramos una soluci\u00f3n en una tecnolog\u00eda llamada federaci\u00f3n de m\u00f3dulos.<\/p>\n\n\n\n
Con el plugin de federaci\u00f3n de m\u00f3dulos de Webpack, pudimos crear una nueva compilaci\u00f3n de nuestra antigua aplicaci\u00f3n con cambios m\u00ednimos<\/b>, que podr\u00eda integrar las funciones existentes en el nuevo stack del portal. Seguir\u00edamos teniendo el objetivo a largo plazo de portar el c\u00f3digo ahora heredado a est\u00e1ndares m\u00e1s nuevos, pero esto nos permitir\u00eda empezar a escribir nuevas funciones con los nuevos beneficios inmediatamente.<\/p>\n\n\n\nTenemos un plan, pero \u00bfpodemos hacerlo realidad?<\/h2>\n\n\n\n
Sab\u00edamos que consolidar nuestras plataformas mientras segu\u00edamos aumentando las funciones y los conjuntos de productos requerir\u00eda un esfuerzo masivo, y nuestra planificaci\u00f3n influy\u00f3 en lo que quer\u00edamos para nuestro nuevo stack de front-end y en c\u00f3mo \u00edbamos a gestionar el interminable legado de los sistemas de estilos CSS anticuados, los patrones de componentes de clase obsoletos y la torpe gesti\u00f3n del estado de la aplicaci\u00f3n.<\/p>\n\n\n\n
Como lo est\u00e1bamos construyendo desde cero, especialmente con el paso de AWS a Google Cloud, la mejor soluci\u00f3n era hacer borr\u00f3n y cuenta nueva<\/b>. Un nuevo repositorio con mejores y m\u00e1s altos est\u00e1ndares, federaci\u00f3n de m\u00f3dulos, bibliotecas modulares compartidas y una documentaci\u00f3n m\u00e1s completa a nivel interno y orientada al usuario.<\/p>\n\n\n\nFue una etapa intensa de planificaci\u00f3n y preparaci\u00f3n. Como en todos los grandes proyectos, generar las ideas y la prueba de concepto fue un esfuerzo t\u00e9cnico y creativo en el que solo participaron unas pocas personas seleccionadas.<\/p>\n\n\n\n
\u00bfFase 2? Convertir la idea en realidad, y eso implicaba a muchos m\u00e1s equipos. Desarrolladores, creo que nuestra aventura est\u00e1 a punto de dar un giro muy interesante. <\/p>\n\n\n\r\n