CI/CD para microfrontends: pipelines independientes, descubrimiento y rollbacks
El despliegue independiente es la razón para adoptar microfrontends. Si un equipo no puede llevar su propio cambio a producción sin construir ni publicar nada más, la arquitectura no está entregando lo que cuesta.
El objetivo
Un equipo hace merge de un cambio en su remoto. Ese cambio llega a producción sin construir, probar ni desplegar el host ni ningún otro remoto.
Un pipeline por remoto
- Construir solo este remoto. En un monorepo, herramientas como Nx detectan qué proyectos afecta un cambio, y el resto se omite.
- Probarlo de forma aislada: pruebas unitarias, pruebas de componentes, lint.
- Verificar el contrato. Las versiones de las dependencias compartidas están dentro de la política de plataforma, y los módulos expuestos siguen existiendo con los mismos nombres.
- Publicar artefactos inmutables. Sube el build a una ruta versionada en un hosting estático o un CDN, por ejemplo
/billing/1.42.0/. Una versión publicada nunca se sobrescribe. - Desplegar en un ambiente de preview o staging y correr un smoke test corto contra el producto compuesto.
- Promover. Cambia el puntero que le dice al host qué versión cargar.
- Verificar en producción con unas pocas pruebas automáticas, y revertir de forma automática si fallan.
Los pasos 4 y 6 están separados a propósito. Publicar deja una versión disponible. Promover la pone en vivo.
Descubrimiento: cómo encuentra el host a los remotos
| Enfoque | Cómo funciona | Pros y contras |
|---|---|---|
| URLs fijas en el build del host | Las direcciones de los remotos son parte de la configuración del host en tiempo de build | Simple. Agregar o mover un remoto necesita una publicación del host |
| Una URL estable por remoto | El host siempre carga la misma dirección, y cada despliegue sobrescribe el archivo que hay detrás | Simple. El caché tiene que ser exacto, revertir significa volver a desplegar y cuesta saber qué está en vivo |
| Manifiesto | Al iniciar, el host descarga un archivo JSON pequeño que asocia nombres de remotos con URLs versionadas | Una pieza móvil más. Las versiones son explícitas, el rollback es inmediato y cada ambiente tiene su propio manifiesto |
Un manifiesto se ve así:
{
"billing": "https://cdn.example.com/billing/1.42.0/remoteEntry.json",
"catalog": "https://cdn.example.com/catalog/3.7.1/remoteEntry.json"
}Con un manifiesto, promover una publicación significa cambiar una línea. Ese cambio debería pasar por un paso controlado y con registro de auditoría: un job del pipeline, o un servicio pequeño con control de acceso.
Reglas de caché
- Archivos versionados y con hash: caché largo, marcados como inmutables.
- El manifiesto y los archivos remote entry: caché corto con revalidación. Si se cachean por mucho tiempo, los usuarios se quedan con versiones viejas, o reciben un archivo de entrada que apunta a chunks que ya no existen.
- Las versiones anteriores siguen disponibles. Los usuarios con una pestaña abierta siguen pidiendo chunks de la versión anterior. Mantén los artefactos pasados en línea durante días o semanas antes de limpiar.
Versionado
- Cada remoto tiene su propia versión. Un hash de commit en la ruta o en los metadatos del artefacto conecta cada archivo en producción con su código fuente.
- Las versiones que importan entre equipos son las de los contratos: las librerías compartidas, el design system y la API del host. Las reglas están en Dependencias compartidas y versiones.
- Conserva el historial del manifiesto. Registra qué combinación de versiones estaba en vivo en cada momento, que es la primera pregunta en un incidente.
Rollbacks
Revertir significa apuntar el manifiesto a la versión anterior. Toma segundos y no necesita un build. Tres condiciones lo hacen posible:
- Los artefactos son inmutables y las versiones anteriores se conservan.
- El backend sigue aceptando peticiones de la versión anterior del frontend. Los cambios de API primero agregan, y las eliminaciones llegan después.
- Una funcionalidad que abarca varios remotos queda detrás de un feature flag, de modo que lanzarla es algo separado de desplegarla.
Lo que ve el usuario cuando un remoto falla en producción se cubre en Aislamiento de errores y resiliencia.
Ambientes de preview
Un ambiente completo por rama es caro cuando el producto son diez aplicaciones. Hay un patrón más liviano que funciona bien:
- El pipeline del pull request publica el build del remoto bajo una ruta única.
- Quien revisa abre el host de staging con un override, por ejemplo un query param, que dice "carga billing desde esta ruta".
- Todo lo demás viene de staging como siempre.
Un override que carga un remoto desde una URL arbitraria es un mecanismo de inyección de scripts. Desactívalo en producción, o restríngelo a una lista de orígenes permitidos y a usuarios autorizados.
El mismo mecanismo permite que un desarrollador corra un remoto en su máquina contra un host desplegado. Mira Desarrollo local con microfrontends.
El pipeline del host
El host sigue las mismas etapas con controles más estrictos, porque su radio de impacto es todo el producto. Antes de promover, un smoke test carga cada remoto listado en el manifiesto y verifica que cada uno se muestre. Las publicaciones del host son menos frecuentes que las de los remotos, y eso es sano.
Checklist
- ¿Un equipo puede desplegar a producción sin que corra ningún otro pipeline?
- ¿Los artefactos publicados son inmutables y están versionados?
- ¿Puedes revertir un remoto en menos de un minuto, sin un build?
- ¿El override de preview está desactivado o restringido en producción?
Más en esta sección
- Aislamiento de errores y resiliencia en microfrontends
- Rendimiento de microfrontends: los costos y cómo controlarlos
- Pruebas en microfrontends: una estrategia práctica
- Monorepo vs polirepo para microfrontends
¿Planeas una migración o una plataforma de microfrontends?
En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.
Escríbeme por LinkedIn