Distrito Telefónica. Hub de Innovación y Talento

Volver
Development

Automatización de Fichas de Diseño: Mejora en el Proceso de Desarrollo

Debido al tipo de proyecto en el que trabajamos, tenemos que ser compatibles con diferentes marcas de aplicaciones. Desde el punto de vista del diseño, tenemos distintos temas, cada uno de ellos con colores, radios, fuentes y tamaños diferentes. Para gestionar todas estas opciones que dependen de la marca, el equipo de diseño creó una lista de fichas que tienen un valor diferente según el tema. Estas fichas se utilizan en los diseños en Figma para poder generarlas para todas las marcas sin necesidad de cambiarlas una a una. El uso de estos tokens es beneficioso para los equipos de diseño y desarrollo porque ambos tienen un catálogo claro con todo lo que hay que cambiar teniendo en cuenta la marca. Para evitar problemas y tener un lenguaje común, estos tokens se exportan como un archivo JSON por marca y se gestionan en su propio repositorio de GitHub permitiéndonos tener diferentes ramas y un histórico con todos los cambios.

La forma original de trabajar

Cuando empezamos a tokenizar cosas como los colores, la forma de trabajar era:

  • El equipo de diseño crea/actualiza las fichas de color.
  • El equipo de diseño crea tres tickets de Jira para cada equipo de desarrollo (Android, iOS y Web).
  • Cada equipo de desarrollo aplica estos cambios manualmente en su propio repositorio.
Esta forma de trabajar era la ideal al principio, pero conllevaba varios problemas:

  • Cada cambio mínimo en los tokens debía tener un ticket Jira. Se trataba de una tarea manual que podía dar lugar a errores humanos, ya que era fácil olvidarse de añadir algunos de los cambios.
  • Era una tarea repetitiva sin ningún valor al final.
  • Los pequeños errores en el flujo, como por ejemplo olvidarse de notificar algunos de los cambios, se tradujeron en una revisión de todas las fichas de color una a una (decenas de fichas) por parte del equipo de desarrolladores para actualizar cada una de ellas al valor actualizado. Esto hacía que se perdiera mucho tiempo en una tarea sencilla.

Después de algún tiempo trabajando así, teniendo ese tipo de problemas y viendo los beneficios de usar estos tokens (no solo se usaba para los colores), empezamos un proyecto para automatizar todo este proceso. Tendríamos que invertir algo de tiempo de desarrollo de las tres plataformas, pero pensamos que se compensaría en pocos meses. El objetivo de este proyecto era que, en la mayoría de los casos sin interacción del usuario, las fichas se actualizaran en las tres plataformas cuando el equipo de diseño lo decidiera.

La solución

Decidimos utilizar las acciones de GitHub para automatizar todos estos procesos. La idea era ejecutar una en el repositorio de diseño de Mística que invocaba a los otros tres repositorios para actualizar los tokens a la última versión. Solo ejecutando esta acción de GitHub, se crearían tres PR (uno por plataforma) y el único trabajo de los desarrolladores sería revisar estos PR. Mucho mejor que revisar cada token uno a uno en un JSON para trasladar los cambios al código.
Diagrama del proceso

Diagrama del proceso

La decisión de tener varias acciones de GitHub en lugar de una sola se debió a que cada plataforma es realmente diferente y tiene que generar sus propios archivos o código, por lo que utilizar su propia tecnología simplifica el proceso.

La implementación

En los próximos puntos entraremos en más detalle sobre la implementación que seguimos en cada plataforma.

Android

La versión Android de Mística es compatible con dos implementaciones de los componentes: Android views clásico y Compose. Necesitamos un resultado muy diferente en cada caso. Para las vistas Android, generamos diferentes archivos XML con atributos y estilos que luego utilizamos en nuestro código. Para generar estos archivos XML más fácilmente, utilizamos la biblioteca Kotlin XML Builder. En la versión Compose, tenemos que generar diferentes clases Kotlin. Para ello, utilizamos la biblioteca Kotlin POET para simplificar el proceso de generación del código Kotlin. Puede ver los detalles de nuestra implementación en nuestro repositorio.

iOS

En cuanto a iOS necesitamos generar archivos Swift que definan el protocolo público de las paletas y la implementación específica para cada marca. Decidimos utilizar un generador de código llamado Hygen que nos permite crear múltiples generadores utilizando el lenguaje de plantillas EJS que nos ahorran mucho tiempo y la posibilidad de reutilizarlos por separado. Puedes ver los detalles de nuestra implementación en nuestro repositorio.

Web

En la web, tenemos un script en Javascript que genera un archivo JS por marca con toda la información necesaria en su interior. Puedes ver los detalles de nuestra implementación en nuestro repositorio.

Conclusión

El desarrollo de este proyecto llevó algunas semanas a diferentes personas, pero en cuanto llegaron los primeros cambios en las fichas, vimos la gran mejora que esperábamos. Los cambios en varios colores que antes eran una pesadilla, ahora son solo un par de clics, lo que permite a los equipos concentrarse en las tareas que nos aportan más valor. Puedes ver aquí el tipo de PR que generan nuestras acciones en GitHub. Muchos cambios que se realizan automáticamente.