Proyecto Ledger Live Monorepo: Parte 1 – Problemáticas (Make it Pain) | Libro mayor

En esta serie de publicaciones de blog, Valentin De Almeida, un desarrollador de Ledger Live, nos habla de la evolución del código base de Ledger Live a lo largo de los años. En esta publicación de blog, aprenderá que al principio estaba basado en múltiples repositorios, los problemas que encontramos en el camino y por qué necesitaba evolucionar a una arquitectura de un solo repositorio. En las próximas publicaciones del blog, explicaremos cómo se llevó a cabo este importante proyecto de migración. 

Un poquito de historia 

El crecimiento de Ledger en 2020 y 2021 fue significativo. Reclutamos agresivamente nuevos talentos, ampliando nuestro equipo de unos pocos a más de 20 desarrolladores. Esto significa que se incorporaron muchos ingenieros nuevos a proyectos existentes. A medida que nuestro equipo crecía rápidamente, nos encontramos con nuevos desafíos que tuvimos que abordar rápidamente. A pesar de estas nuevas dificultades, nos mantuvimos enfocados en nuestro objetivo y continuamos realizando un trabajo excepcional.

Dimos un paso atrás y analizamos los nuevos problemas que surgen cuando más y más personas se incorporan al proyecto. Entre esos nuevos desafíos, podemos enumerar las siguientes necesidades:

• Flujos más simples.
• Mejores directrices para los contribuyentes entrantes y externos.
• Un conjunto unificado de herramientas.
• Mejor gestión de la dependencia.
• Contribuciones centralizadas de código abierto.

Estado del Arte: antes de la migración

Inicialmente, y hasta el año pasado, Ledger Live se basaba en una arquitectura de poli-repositorio, tanto para front-end móviles como de escritorio, así como toda la lógica detrás de ella. No fue una decisión consciente trabajar de esta manera, sino sólo el resultado de un proyecto en expansión sin una verdadera orientación arquitectónica. Ledger Live es un proyecto que reúne varios componentes en uno para ofrecer la mejor y más segura aplicación a nuestros usuarios de Nano, y se reflejó en el código base.

Los flujos que teníamos eran, en el mejor de los casos, inestables, principalmente debido al hecho de que éramos 6 o 7 desarrolladores hace un par de años. Como había menos partes involucradas, la comunicación fue mucho más fácil y nos salimos con la nuestra. Aún así, hubo algunos puntos débiles en la forma en que estábamos trabajando, especialmente en torno a la experiencia del desarrollador y el proceso de lanzamiento.

Cuellos de botella en la experiencia del desarrollador

Dependencias

Debido a la naturaleza de nuestros proyectos, trabajamos en múltiples repositorios al mismo tiempo, con dependencias entre ellos. Aquí hay una descripción general rápida:

Las bibliotecas de código abierto de Ledger son utilizadas por la lógica empresarial, que luego es utilizada tanto por las aplicaciones móviles como de escritorio. Pero esas aplicaciones también usan bibliotecas de código abierto y usan dos versiones diferentes de la misma biblioteca (como @ledgerhq/errors por ejemplo) rompería la aplicación.

Necesitábamos aumentar la versión en un lado, luego publicar las bibliotecas (sí, ¡¡¡en npm!!!) y luego intentarlo nuevamente si no funcionaba. Empezamos a confiar en yalc a proyectos de enlaces simbólicos, lo cual estaba bien siempre y cuando no tuviéramos varias capas de dependencias (por ejemplo, desde las bibliotecas de código abierto hasta la lógica de negocios, y luego desde la lógica de negocios hasta las aplicaciones). Intentamos tentativamente trabajar con yarn link también, pero parece que estaba condenado al fracaso con React Native.

Pruebas

Era casi imposible hacer pruebas de integración con el código más reciente de los diferentes proyectos. Como necesitábamos publicar las bibliotecas en el registro, probar todos los componentes con el código más actualizado fue una pesadilla.

También tuvimos que mantener varios CI con lógica duplicada.

Cambio de contexto

Mover constantemente entre varios editores de código/proyectos/directorios hacía que la experiencia del desarrollador pareciera realmente débil.

Cuellos de botella en el proceso de lanzamiento

Versiones

Manejar el control de versiones de diferentes proyectos es difícil, especialmente cuando hay varias capas de dependencias.

Liberando

El seguimiento de los lanzamientos era complicado debido a que los proyectos estaban divididos y teníamos que gestionar los lanzamientos de los diferentes proyectos.

Fue imposible automatizar el proceso de lanzamiento, nuevamente debido al hecho de que los proyectos estaban divididos en diferentes repositorios.

Y, por supuesto, la entrega continua era impensable en ese momento.

Solución posible ?

Mirando a nuestro alrededor en busca de inspiración, parece que una arquitectura de repositorio mono es la pieza central que nos faltaba. Permitiría un proceso de desarrollo mucho mejor. Existen herramientas construidas alrededor de esta arquitectura que nos ayudarían a lograr las partes que faltan (lanzamiento, automatización, control de versiones…).

Pero, ¿qué es un repositorio mono?

En esencia, un repositorio mono es un proyecto que encapsula todos los demás proyectos relacionados (aplicaciones, bibliotecas, herramientas) en una carpeta/proyecto git. Permite una mejor gestión de dependencias, uniformización de herramientas (como estilos de código y configuraciones de mecanografiado), integración continua centralizada, pruebas de integración, versión uniforme de paquetes usados ​​(reaccionar, por ejemplo)...

Dado que es un sistema bastante agnóstico, nos dejaron algunas características para descubrir e implementar. Con suerte, existen algunas herramientas comunitarias excelentes que podrían ayudarnos a agregar orquestación a las compilaciones (compilaciones secuenciales, útiles para CI), control de versiones, generación de registros de cambios... lo que completaría lo que nos faltaba en nuestro proceso de lanzamiento.

Desventajas

Los repositorios mono tienen sentido en un contexto donde varios desarrolladores, o un equipo de desarrolladores, trabajan en varios proyectos al mismo tiempo, con dependencias entre ellos. Sin embargo, agrega cierta capa de complejidad durante la fase de configuración (especialmente con proyectos ya en funcionamiento que tienen 4 años de historia y desarrollo activo). Vale la pena mencionar que el proyecto se vuelve mucho más grande (mucho más grande) en términos de espacio en disco. Todos los proyectos ahora están en la misma carpeta y todas las dependencias. ¿Qué pruebas son obligatorias? ¿Cuándo activarlos?

Para Agencias y Operadores

Después de evaluar el tiempo, el costo y la viabilidad de nuestras ambiciones, estos fueron algunos de los beneficios esperados de esta transición:

• Gestión de dependencias mejorada: con un monorepo, es más fácil gestionar las dependencias entre diferentes proyectos, ya que todos están almacenados en el mismo repositorio. Esto puede reducir la necesidad de soluciones alternativas como eslabón de hilo o yalcy facilitará la tarea de garantizar que todos los proyectos utilicen las versiones correctas de las dependencias.
• Mejor organización del código: un monorepo puede facilitar la organización del código, ya que todos los proyectos y sus dependencias se almacenan en un único repositorio. Es más fácil entender cómo encajan los diferentes proyectos y cómo dependen unos de otros.
• Experiencia de desarrollador mejorada: un monorepo puede facilitar que los desarrolladores trabajen en múltiples proyectos, ya que no necesitan cambiar entre diferentes bases de código o repositorios. También puede facilitar la ejecución de pruebas de integración, ya que todo el código se almacena en el mismo repositorio.
• Automatización mejorada y entrega continua: con un monorepo, es más fácil automatizar tareas como crear, probar y publicar código. Esto puede ayudar a agilizar el proceso de lanzamiento y facilitar la implementación de la entrega continua.
• Mayor velocidad de desarrollo. Dado que diferentes equipos trabajan en el mismo repositorio, no necesitan esperar hasta el lanzamiento para verificar el resultado, lo que acelera la integración.

Conclusión

En general, la implementación de una estructura monorepo puede ayudar a mejorar el proceso de desarrollo, agilizar el proceso de lanzamiento y mejorar la experiencia del desarrollador.

En las próximas publicaciones de blog de esta serie, le explicaremos cómo se llevó a cabo este importante proyecto de migración, las herramientas que utilizamos, las decisiones que tomamos, el resultado y más. Estén atentos a la Parte 2: ¡Las herramientas!

---

Valentín DE ALMEIDA
Experiencia de desarrollador y tecnología central: Ledger Live

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain