Saltar al contenido principal

manager

Ver en Git

mFE Manager

El mFE_manager consta de:

  • API:
    1. recibe desde el CICD de cada microfrontend el build del commit para hacer el seguimiento de las versiones. Crea la nueva versión del microfrontend y sube el build a s3.
    2. Tiene el back de la consola de microfrontends, con la que se administran los deployments. Acá se hace el ABM de microfrontends, proyectos y se administra el versionado.
    3. Es el servicio de discovery de la nueva arquitectura. La arquitectura cuando arranca le consulta a este servicio qué versiones de cada microfrontend debe cargar.
  • Script
    • Sincroniza s3 con el servidor que sirve el contenido estático

Se definen:

  • micro-frontends (mfes): es básicamente un repo, un proyecto de front
  • versiones: cada commit sobre branches específicas.
  • proyectos: se puede hacer una analogía con un cliente. La nueva arquitectura usa el id de proyecto para identificarse. Podría utilizarse como identificador de entorno (preprod, testing1, testing2, etc.) o como proyectos distintos.
  • views: vincula un proyecto con los mfes que puede ver y qué versión de cada uno. Es el deployment

Rápidamente el flujo es el siguiente:

  1. Un administrador crea un proyecto en el manager
  2. Cuando un developer crea un repositorio de micro-frontend, crea el mfe en el manager
  3. El CICD de cada mfe, al realizar un commit, envía el build al manager, que crea una versión nueva de ese mfe.
  4. Un administrador puede ver todos los proyectos, los mfes y sus versiones. Para un proyecto, elige qué mfes publicar y que versión, creando una view.
  5. La arquitectura se buildea con el proyect_id y consulta qué mfes hay disponibles (discovery). El manager entrega la view para ese proyecto.

El manager es un único repo para todo el front​

Es casi una extensión de git. Lleva todas las versiones del código disponibles y se encarga de publicarlas. Esto implica una complejidad: con un único servicio, se debe poder atender a testing, producción y permitir que múltiples desarrolladores trabajen en branches separadas simultáneamente y aún así mantener un versionado.

La idea es que el manager sólo lleve las branches que necesiten ser deployadas en una view. Si bien el manager acepta cualquier branch, desde el CICD de cada mfe, se filtra para sólo publicar las branches:

  • master/main
  • release-*
  • test-*
  • hotfix-*

Esto implica que los desarrolladores mantengan la nomenclatura.

Versionado​

Para poder llevar un versionado numérico, pero permitir múltiples branches de desarrollo/test en paralelo, cada commit llevará un versionado según el nombre de su branch.

  • Los commits de master/main llevan versionado numérico.
  • Los commits de cualquier otra branch llevan su commit hash como versión

El incremento del versionado numérico lo hace cada front en su CICD cuando hay un merge request, según qué branch se mergea:

  • en MR sube minor si viene de release-* o test-*
  • en MR sube patch si viene de branch X
  • en MR, si el major es distinto, no modificar nada. Los major se modifican en el código

Para poder implementar esto, es necesario que en cada proyecto se respeten ciertas configuraciones:

  • Bloquear push a master, solo se puede hacer por MR
  • Bloquear fast-forward en master, todos los MR deben agregar un commit.

Privacidad de los proyectos y las branches​

Para controlar qué branches se pueden deployar en cada proyecto, cada uno se define como privado o público. Luego, el manager al recibir una nueva versión, según la branch a la que pertenezca el commit, la etiquetará como pública o privada.

  • master: versiones públicas
  • release-*: versiones públicas
  • test-*: versiones privadas
  • hotfix-*: versiones privadas
  • *: versiones privadas

Al momento de crear una view:

  • si el proyecto es público: se pueden asociar versiones públicas
  • si el proyecto es privado: se pueden asociar versiones públicas y privadas

De esta manera, las versiones privadas pueden considerarse como todavía en desarrollo, mientras que las públicas como versiones publicables.

Almacenamiento​

Cuando el CICD de un mfe crea una nueva versión, envía al manager un zip con el build del commit. El manager sube a s3 archivo por archivo y luego el zip entero para mobile. Cada build es subido a un directorio definido por el mfe y la versión.

Las versiones públicas van a un directorio source/public mientras que las privadas a source/private. De esta manera, a nivel servidor se configura quienes pueden acceder a cada directorio, además de esconder private y public del path, permitiendo que solo usuario de dentro de la red accedan a las versiones privadas.

Discovery​

El descovery no es mas que un GET que permite ver las views por proyecto. Sin embargo, a futuro es una manera de controlar qué mostrarle a cada usuario. Podría verse si el usuario está logueado y establecer reglas según espacio, tipo de usuario, etc.

Si se empieza a verificar si un usuario está logueado, se complicaría el uso del manager para testing. En ese caso habria que levantar otro manager en testing, que utilice la misma base de datos, pero que sólo se use para el discovery de testing.