Para facilitar el desarrollo entre proyectos, el equipo que desarrolla el Webmail Infomaniak ha agrupado el código de las aplicaciones en un único repositorio (monorepo). Este enfoque tiene por objeto mejorar los procesos de actualización, facilitar la colaboración y acelerar el cambio del ecosistema. Webmail es un proyecto piloto a gran escala con varias aplicaciones interconectadas (kDrive, Mail, Calendario, Contactos) y más de 1 millón de usuarios habituales. Nuestros desarrolladores hablan de esta transición, sus beneficios, desafíos y también impactos negativos.

El rendimiento de nuestras soluciones, también lo buscaremos en nuestra propia organización y procesos. Julien Arnoux, VP of Engineering en Infomaniak

¿Por qué cambiar a una arquitectura monorepo?

El ciclo de vida del Webmail requiere la adaptación de nuestra estrategia de repositorio de código. Hasta ahora, las diferentes partes (proyectos, bibliotecas) del Webmail se desarrollaban en repositorios de código separados. Un equipo desarrollaba el código de una biblioteca para su proyecto de forma independiente sin que los cambios de versión repercutieran en tiempo real en otros proyectos en curso. El seguimiento se estaba volviendo complejo:

«Los desarrolladores que trabajaban en cambios transversales tenían que identificar y alinear sistemáticamente las versiones de cada librería y los proyectos modificados manualmente. Esto podía dar lugar a una gran cantidad de mantenimiento. La idea era dejar atrás todas esas etapas intermedias y centrarnos en el desarrollo propiamente dicho». Zachary Volpi, Desarrollador Webmail en Infomaniak

Los proyectos también podían desincronizarse si un equipo tenía un ciclo de publicación más rápido que el de otras bibliotecas dependientes. La complejidad de las tareas de publicación y actualización manual en multirepo también aumentaba las tediosas manipulaciones y el riesgo de errores en detrimento de la creación de valor. 

Los beneficios de la arquitectura monorepo

Con esta nueva base, nuestro enfoque DevOps es más eficaz. Los ciclos automatizados permiten compilar, probar e implementar código sin errores (especialmente en el espectro de errores humanos). Estos avances permiten agilizar todos los pasos de entrega de aplicaciones.

1. Intercambio y validación del código simplificados 

Con una arquitectura monorepo, las versiones del código fuente se comparten entre todas las partes del proyecto. Un solo cambio tiene efecto en todas partes sin el riesgo de dañar una funcionalidad adyacente. Ya no es necesario apuntar a la versión adecuada para cada dependencia. Nuestros scripts detectan los proyectos vinculados a una actualización e inician los procesos de validación asociados con las áreas modificadas.

2. Gestión simplificada de los procesos DevOps

La centralización del código permite crear pipelines para todo el proyecto con un enorme ahorro de tiempo llave en mano. Nuestras pipelines de integración continua (CI) y entrega continua (CD) se vuelven más rigurosas con procesos probados, predictivos y repetibles. Esto facilita la adición de nuevos fragmentos de código.

Ahora podemos acoplar pipelines en función de la etapa (build, prueba, implementación). Los trabajos se lanzan en paralelo, lo que era imposible o muy limitado en multirepo. Como todos los conjuntos de prueba son comunes, el desarrollo de las funciones que afectan a varias aplicaciones es mucho más rápido.

3. Mayor colaboración y mejora de la visión de conjunto

Los desarrolladores pueden recuperar e integrar el conjunto de un cambio en curso, lo que mejora la comprensión global. Ya no es necesario navegar por varios proyectos para detectar problemas ocultos, todo está al alcance de la mano. Modificamos y probamos a medida que avanzamos, lo que acorta el ciclo de validación. El cambio de contexto también es más fácil: un desarrollador que trabaja en varios proyectos o que tiene que incorporar el trabajo de un colega puede comparar las diferencias mucho más rápidamente.

4. Mejora de la calidad del código

Ya no tenemos que duplicar, cargar una biblioteca en un proyecto raíz y hacer constantemente esa ida y vuelta. Tener todo el código a mano ayuda a identificar los problemas con mayor rapidez. También podemos aligerar la carga de las aplicaciones eliminando el código muerto sin temor a que se utilice en otros lugares. Compartir el mismo entorno reduce las diferencias entre los equipos.

Cuando modificamos una biblioteca, primero se realizan estas comprobaciones: ¿cumple el código con los estándares actuales? ¿Funciona según lo planeado? A continuación, realizamos pruebas de las aplicaciones que lo utilizan para validar su correcta integración. Es un enfoque de cebolla (por capas), pasando de las pruebas más simples (unitarias) a las más complejas (de extremo a extremo).

5. Aceleración del desarrollo

Monorepo facilita la producción periódica de nuevas funciones. Recuperamos los cambios de otros desarrolladores mucho más rápido. Con la automatización de los procesos, esto hace que la puesta en producción sea más armoniosa. Con el ciclo de retroalimentación acelerado, podemos iterar más rápido.

Pasar al monorepo: ¿qué cambia?

Nada mejor que un diagrama para ilustrar el impacto del monorepo en nuestra organización:

Mejora que requiere varios cambios en las diferentes librerías utilizadas en el proyecto:

Con el monorepo:

La implantación del monorepo en un entorno de producción

Queríamos hacer que la transición fuera totalmente transparente para nuestros clientes y prácticamente transparente para los empleados que trabajaban en el proyecto. 

«A diferencia de un proyecto incipiente, cambiar la organización del código del Webmail implicaba enormes consecuencias, ya que la aplicación está en producción. Es como hacer obras en una carretera principal». Zachary Volpi, Desarrollador Webmail en Infomaniak 

Tuvimos que dividir la transición en varios pasos para evitar un cambio demasiado grande que podría haber provocado una indisponibilidad del servicio, sin posibilidad de revertirlo. Hemos hecho un largo trabajo de preparación y validación:

  • Dividir la migración en varias fases, integrando el impacto potencial para los compañeros.
  • Pruebas de cada etapa anterior siempre que fuera posible.
  • Detalle de cada etapa con una lista de tareas «listas para usarse» para el día D.
  • Planificación de los hitos de migración en períodos de baja afluencia.
  • Simulación de escenarios de crisis para anticiparse a los problemas y prever las medidas que deben adoptarse.

Nuestro equipo también ha desarrollado procedimientos de documentación de incidentes para permitir dar marcha atrás en cierta medida.

La elección de PHP

DevOps es a menudo se escribe en bash o python, raramente en PHP. Las pipelines de DevOps que íbamos a poner en marcha tenían que ser comprensibles para todos nuestros colegas. Nuestras aplicaciones también están escritas en PHP y se puede usar perfectamente para scripting. También teníamos entornos de ejecución configurados y disponibles para otros pasos. Por lo tanto, era más fácil reutilizarlos directamente en lugar de partir de hojas en blanco.

Encontrar el ritmo de cambio correcto

No había que quedarse en períodos de transición prolongados. Por consiguiente, cada tarea debía realizarse a intervalos lo suficientemente largos como para garantizar la seguridad y la estabilidad, pero relativamente cortos para evitar la fragilidad del sistema.

Principales retos de la migración

Migración sin retorno

Esto afectó a todo el flujo de trabajo (estructuración de pasos, extracción de partes comunes, ubicación de archivos, historial de cambios) y a todos los entornos de trabajo del equipo de Webmail (producción, desarrollo, pruebas, lanzamiento de paquetes, notificaciones, etc.). Por consiguiente, era importante que el período de transición no durara demasiado.

En multirepo, cada cambio en un componente requiere ajustar y verificar manualmente cada una de sus dependencias. En monorepo, casi todo está automatizado: tan pronto como se modifica un componente, todo el sistema se actualiza automáticamente. Es como pasar de transmisión manual a automática en un coche. ¡Todo es más sencillo! Julien Arnoux, VP of Engineering en Infomaniak

Pensar y anticipar todas las posibilidades

Es paradójico, pero ha habido que pasar por una gran complejidad para simplificarlo todo. Centralizar el código implica repensarlo todo. Para definir las lógicas de activación de las pipelines, necesitábamos entender su impacto en cada proyecto y desarrollar la detección del contexto que las acompaña, para:

  • las fases (Continuous Integration + Continuous Development)
  • las tareas comunes a las apps y bibliotecas
  • las diferentes fases de build
  • Realización de las pruebas y validaciones de las partes interesadas

El principal problema ha sido que no podíamos probar todos los pasos en condiciones reales, en especial, los del entorno de producción. Gracias a la capacidad de concentración de las definiciones de gitlab-ci, hemos sido capaces de separar nuestros scripts por tema y área de impacto. Esto ha reducido drásticamente la duplicación de archivos y otros problemas de copiar y pegar.

Balance: ¿monorepo o multirepo? 

¿Ha sido una buena idea cambiar a monorepo? La respuesta es sí.

Esta nueva organización ofrece grandes ventajas:

  • Recuperación simplificada de los cambios.
  • Compartición de la configuración de algunas herramientas.
  • Reducción del mantenimiento al realizar cambios en múltiples aplicaciones.
  • Simplificación del desarrollo: todo está en el mismo lugar y es mucho más fácil navegar entre las áreas.

Este desarrollo también tiene impactos negativos:

  • No es tan fácil detectar cambios como en un repositorio convencional. La curva de aprendizaje de un recién llegado es un poco más larga.
  • Se necesita un buen conocimiento de las herramientas CI / CD, incluyendo gitlab-ci, para hacer ajustes en las pipelines.

Los desarrolladores que han gestionado el cambio a monorepo

Julien Arnoux, VP of Engineering en Infomaniak (pero siempre con las manos en la masa):

Llevo 15 años desarrollando y me encanta todo lo relacionado con la automatización de nuestros flujos de trabajo. Cuando estoy desarrollando y según mi estado de ánimo, puedo escuchar tanto hard-rock/metal como drum’n’bass. De hecho, escucho un poco de todo, pero estos dos estilos son mi impulso 😅

Zachary Volpi, Desarrollador full stack del equipo de Webmail:

Comencé a desarrollar en agosto de 2014. Me gusta tener la visión (y la comprensión) de todos los aspectos del desarrollo de aplicaciones. Siempre estoy buscando soluciones para simplificar un proceso u obtener un mayor rendimiento. Para acompañar mis sesiones, adapto la música según lo que quiero hacer: desde el chill al dub o al metal. En cuanto a las referencias, encuentro el blog de logrocket muy pertinente. Tienen artículos muy bien diseñados sobre temas muy amplios y avanzados. Por lo demás, sigo directamente los canales de las herramientas que utilizo (en X & LinkedIn principalmente).

¿Deberías usar también una arquitectura monorepo?

Habla con nuestros desarrolladores en X.