Gestión de versiones en la fuente de la verdad
Esta semana veremos qué opciones tenemos para mantener una fuente de la verdad centralizada
En el artículo de esta semana vamos a hablar de la fuente de la verdad en design tokens, de la ubicación de esta y de quién debería de tener el ownership de los cambios.
Tener esto bien definido desde el principio nos ahorrará dolores de cabeza y problemas de versionado.
Introducción
Cuando hablamos de design tokens y de sistemas de diseño en general, nos suelen hacer chiribitas los ojos cuando pensamos en la posibilidad de tener todas nuestras decisiones centralizadas, hasta tal punto, que un cambio en un sitio haga que todos nuestros productos se actualicen en consecuencia.
Es importante hacer notar que esto no es una característica intrínseca de los tokens de diseño, sino más bien un síntoma, en este caso positivo.
Cuando todas nuestras decisiones están centralizadas es más fácil implementar este tipo de funcionalidades, pero al final no hay que perder de vista que aunque nuestras decisiones vivan en un único lugar, los cambios pueden tardar un tiempo en distribuirse a los diferentes proyectos y productos.
De igual forma, es posible optar por un enfoque distribuido a la hora de mantener nuestros design tokens. Esto puede tener sentido cuando hay cambios de diseño muy drásticos entre plataformas, por lo que quizá es interesante no mantener en este caso los tokens en una única fuente de verdad.
Enfoque centralizado
En un sistema centralizado, todos los tokens de diseño (como colores, tipografías, espaciados, etc.) están almacenados y gestionados en un único repositorio o fuente de la verdad.
Los tokens se actualizan y mantienen en un solo lugar, lo cual facilita la implementación de cambios a nivel global. Normalmente, hay un equipo encargado de la gestión y mantenimiento de los tokens.
Este enfoque asegura una mayor consistencia en todos los productos, ya que todas las partes del sistema utilizan las mismas decisiones.
Sin embargo, un sistema de tokens centralizado puede ser más difícil de escalar en organizaciones grandes con múltiples productos, marcas o equipos de desarrollo independientes, ya que es menos flexible y menos adaptable a necesidades específicas.
En resumen, este enfoque nos permite tener una velocidad de desarrollo más eficiente, ya que los cambios y actualizaciones se pueden propagar rápidamente a través del sistema.
Enfoque descentralizado
En un sistema distribuido, los tokens de diseño pueden estar almacenados en múltiples fuentes, y gestionados por diferentes equipos o departamentos dentro de la organización.
Este sistema es mucho más flexible y escalable ya que permite reflejar mejor las necesidades específicas de cada área de la organización.
Sin embargo, requiere coordinación para asegurar que los tokens se mantengan alineados. Puede ser más difícil mantener la consistencia total en todo el sistema, ya que diferentes partes de la organización pueden utilizar variantes ligeramente diferentes de los mismos tokens.
La velocidad de desarrollo también es más lenta con respecto al enfoque centralizado ya que hay que coordinar a un mayor número de equipos.
Lamentablemente, muchas veces en las empresas nos encontramos equipos que funcionan siguiendo un enfoque de descentralización, y tratamos de implementar un sistema de diseño que compre las bondades de un enfoque centralizado.
Si no hay una buena comunicación y tendencia al cambio, puede ser complicado cambiar la forma de pensar y acabaremos con un mix entre ambos panoramas: centralización de tokens bajo una única fuente de la verdad, pero con decisiones demasiado ad-hoc para ciertas casuísticas.
Dónde tener la fuente de la verdad centralizada
Si optamos por seguir el enfoque de una única fuente de la verdad gestionada por un equipo, es importante que esta viva en un único lugar físico y esté versionada.
Por ejemplo, podría ser interesante tener nuestra fuente representada en ficheros JSON (como hemos visto en el pasado) y versionada usando Git.
Finalmente, podríamos tener la fuente en un repositorio público o privado como Github o Bitbucket de tal forma que todos los equipos puedan consumirla desde ahí.
Git
Es un sistema de seguimiento para el código de un proyecto, como si de un libro de registros se tratase. Aquí, cada cambio en el código se anota con detalles, como quién hizo el cambio, qué se cambió y por qué. Esto facilita volver atrás si algo no funciona, ver quién trabajó en qué, y entender el progreso del desarrollo.
Aunque git es el sistema idóneo para versionar la fuente de la verdad de tokens, es muy importante seguir unos estándares a la hora de agregar modificaciones.
Git flow
Para empezar es muy importante tener una política para introducir cambios en la fuente de la verdad, ya que de no tenerla, varios miembros del equipo podrían introducir cambios en paralelo y encontrarse con conflictos.
Git Flow es una metodología de ramificación de Git diseñada para facilitar la gestión del desarrollo y despliegue de software. Fue introducida por Vincent Driessen en 2010 y proporciona una estructura clara para organizar el trabajo en ramas y manejar versiones de software.
Así, cuando tenemos los tokens en repositorio de git la rama ‘main’ siempre contiene los tokens de producción (la versión más reciente). Del mismo modo, los cambios para la siguiente versión viven en la rama ‘develop’ y es donde el equipo va metiendo el trabajo diario.
Cuando se prepara una nueva versión, se genera una nueva rama llamada ‘release’ con todo el código destinado a ser el nuevo ‘main’ en el futuro.
En este punto el sistema de gestión de versiones nos permite que los equipos estén usando la última versión (en la rama main y normalmente llamada versión release), la versión más reciente (en la rama develop y llamada versión beta) y la siguiente versión que estará disponible pronto (en la rama release y que recibe el nombre de versión release candidate).
Repositorio remoto
Para que todo esto pueda ser consumido por uno o más equipos de desarrollo, necesitamos alojar este repositorio de git con los tokens de forma remota.
Dependiendo de las necesidades podríamos optar por tener los tokens en Github (que ofrece repositorios tanto públicos como privados), en bitbucket o en un servidor propio.
Además, podríamos configurar herramientas como Token Studio para que tomasen sus datos de estas fuentes remotas, y así UX y DEV escribirían y consumirían al mismo canal, proporcionando una alta velocidad de propagación de cambios.
Conclusión
Hoy hemos visto una introducción a los dos enfoques que tenemos para gestionar una fuente de la verdad y cómo utilizar el enfoque centralizado con las herramientas y técnicas de las que disponemos.
En futuras entregas mostraremos ejemplos concretos de cómo consumir la fuente de la verdad y propagar estos cambios.
Espero que os haya gustado este post y os pedimos el favor de siempre: Dadle like si os ha gustado y compartirlo en vuestras redes sociales!