Concepto clave
Los pipelines de CI/CD para micro-frontends con Module Federation son sistemas automatizados que gestionan la construccion, prueba y despliegue de aplicaciones distribuidas. Imagina una cadena de montaje en una fabrica de coches: cada micro-frontend es un componente (motor, chasis, interior) que se ensambla de forma independiente, pero debe integrarse perfectamente en el vehiculo final. El pipeline asegura que cada pieza cumpla con estandares de calidad antes de llegar a produccion.
La principal diferencia con aplicaciones monolíticas es la coordinacion entre modulos federados. Mientras un pipeline tradicional construye un solo artefacto, aqui gestionas multiples builds que deben ser compatibles en versiones y dependencias. Es como orquestar una orquesta donde cada músico (micro-frontend) practica por separado, pero el director (pipeline) asegura que todos toquen en armonia durante el concierto (produccion).
Como funciona en la practica
Un pipeline tipico para micro-frontends sigue estos pasos:
- Trigger: Se activa al detectar cambios en un repositorio Git (ej: push a main).
- Build paralelo: Cada micro-frontend se construye independientemente usando Webpack con Module Federation.
- Pruebas de integracion: Se verifica que los modulos federados se comuniquen correctamente.
- Versionado semantico: Se asignan versiones compatibles a todos los micro-frontends.
- Despliegue gradual: Se publican primero en staging, luego en produccion con estrategias como blue-green.
Ejemplo con dos equipos: el equipo "Productos" actualiza su micro-frontend. El pipeline construye solo ese modulo, ejecuta sus tests unitarios, luego tests de integracion con el micro-frontend "Carrito" (que permanece inalterado), y finalmente despliega la nueva version si todo pasa.
Codigo en accion
Configuracion basica de un pipeline en GitHub Actions para un micro-frontend "auth":
name: CI/CD for Auth MF
on:
push:
branches: [main]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
- name: Install dependencies
run: npm ci
- name: Build with Webpack
run: npm run build
env:
NODE_ENV: production
- name: Run unit tests
run: npm test
- name: Integration test with container
run: |
npm run start:container &
sleep 10
npm run test:integration
- name: Deploy to staging
if: success()
run: npm run deploy:stagingConfiguracion de Module Federation en webpack.config.js para manejar versiones en CI/CD:
const { ModuleFederationPlugin } = require('webpack').container;
const packageJson = require('./package.json');
module.exports = {
// ... otras configuraciones
plugins: [
new ModuleFederationPlugin({
name: 'auth',
filename: 'remoteEntry.js',
exposes: {
'./Login': './src/components/Login',
},
shared: {
react: {
singleton: true,
requiredVersion: packageJson.dependencies.react,
},
'react-dom': {
singleton: true,
requiredVersion: packageJson.dependencies['react-dom'],
},
},
}),
],
};Errores comunes
- Versionado inconsistente: Desplegar micro-frontends con versiones incompatibles de dependencias compartidas (ej: React 18 en uno y 17 en otro). Solucion: Usar singleton: true en shared y fijar versiones exactas en package.json.
- Falta de pruebas de integracion: Asumir que si cada modulo pasa tests unitarios, funcionaran juntos. Esto causa errores en runtime. Solucion: Incluir tests E2E que simulen la aplicacion completa en el pipeline.
- Despliegue no atomico: Actualizar micro-frontends de uno en uno, creando ventanas donde versiones viejas y nuevas coexisten. Solucion: Implementar despliegues blue-green o canary donde todos los modulos se actualizan simultaneamente.
- Ignorar el remoteEntry.js: No versionar o cachear correctamente este archivo, rompiendo la carga de modulos. Solucion: Usar hashes en el nombre (ej: remoteEntry.[contenthash].js) y estrategias de cache CDN.
Checklist de dominio
- ¿Tu pipeline construye cada micro-frontend en paralelo para reducir tiempo?
- ¿Incluye pruebas de integracion entre modulos federados?
- ¿Maneja versionado semantico coordinado entre todos los micro-frontends?
- ¿Usa estrategias de despliegue sin downtime (blue-green, canary)?
- ¿Configura shared dependencies con singleton: true en Module Federation?
- ¿Versiona remoteEntry.js con hashes para evitar problemas de cache?
- ¿Tiene rollback automatico si fallan las pruebas en produccion?
Implementar un pipeline CI/CD para dos micro-frontends con integracion
Configura un pipeline que construya y despliegue dos micro-frontends ("productos" y "carrito") que usen Module Federation.
- Crea dos repositorios Git simulados (pueden ser carpetas locales) para cada micro-frontend.
- Configura un archivo de pipeline (ej: .github/workflows/pipeline.yml) que:
- Se active al hacer push a main en cualquiera de los repositorios.
- Construya ambos micro-frontends usando
npm run build. - Ejecute tests unitarios para cada uno.
- Levante un contenedor con ambos micro-frontends y ejecute un test de integracion que verifique que el modulo "carrito" puede importar un componente de "productos".
- Si todo pasa, despliegue los archivos construidos a una carpeta "dist" compartida (simulando un CDN).
- Asegurate de que la configuracion de Module Federation en ambos proyectos use shared dependencies para React.
- Prueba el pipeline haciendo un cambio en uno de los micro-frontends y verificando que se ejecuten todos los pasos.
- Usa GitHub Actions o GitLab CI segun tu preferencia, la estructura es similar.
- Para tests de integracion, puedes usar Puppeteer o Cypress para simular la carga de los modulos.
- Asegurate de que el remoteEntry.js de cada micro-frontend sea accesible en la ruta correcta durante las pruebas.
Evalua tu comprension
Completa el quiz interactivo de arriba para ganar XP.