Next.js
CI/CD para Next.js
Diseña un pipeline CI/CD reproducible para Next.js con lint, tipos, tests, build, previews, migraciones, promoción, observabilidad y rollback.
- Última actualización
- Actualizada
- Nivel
- Aplicación
Next.js
Diseña un pipeline CI/CD reproducible para Next.js con lint, tipos, tests, build, previews, migraciones, promoción, observabilidad y rollback.
CI/CD convierte el código en un artefacto verificable y desplegable mediante pasos repetibles. Un buen pipeline no solo ejecuta next build: controla versiones, secrets, migraciones, previews, pruebas, promoción, rollback y evidencia de qué commit llegó a cada entorno.
commit / pull request
→ install reproducible dependencies
→ lint + typecheck + tests
→ production build
→ preview deployment
→ integration and smoke tests
→ approve/promote
→ database migration
→ production deployment
→ verify and observe
→ rollback if necessaryCada etapa debe fallar de forma clara y no depender del estado accidental de una máquina.
Fija:
.nvmrc, .node-version, Volta o engines.packageManager.Instalación:
pnpm install --frozen-lockfileNo permitas que CI actualice dependencias implícitamente. Un build reproducible debe producir el mismo resultado a partir del mismo commit y configuración.
pnpm lint
pnpm typecheck
pnpm test
pnpm buildCada comando detecta problemas distintos:
next build: rutas, boundaries, prerender, imports y configuración de producción.No reemplaces next build con tsc; el framework analiza más cosas.
name: CI
on:
pull_request:
push:
branches: [main]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
- uses: actions/setup-node@v4
with:
node-version-file: .nvmrc
cache: pnpm
- run: pnpm install --frozen-lockfile
- run: pnpm lint
- run: pnpm typecheck
- run: pnpm test --run
- run: pnpm buildVersiona las actions por versión o commit confiable y revisa actualizaciones de supply chain.
Clasifica:
public build values
server runtime secrets
CI-only credentials
preview credentials
production credentialsPrincipios:
env completo.NEXT_PUBLIC_* existe durante build y queda en el bundle. Cambiarlo después sin reconstruir no cambia el cliente.
Cada pull request puede producir una URL temporal:
PR
→ isolated build
→ preview URL
→ visual review + E2E
→ approvalConfigura preview con:
noindex.No conectes previews arbitrarios a datos reales de clientes.
Schemas, mappers, policy functions y lógica pura.
Client Components, formularios, estados y accesibilidad.
Actions, DAL, DB, Route Handlers y proveedores simulados.
Flujos críticos sobre un build real:
No intentes cubrir todo con E2E: son más lentos y frágiles.
Una release puede implicar:
code version A
migration
code version BDurante despliegues progresivos, A y B pueden coexistir. Usa expand/contract:
Evita:
rename/drop column
→ old instances still running
→ runtime failureLas migraciones deben tener:
No ejecutes una migración automáticamente desde cada réplica al iniciar.
Depende del cambio:
migration first
→ deploy new codedeploy code that no longer uses old field
→ verify
→ remove field laterNo existe un orden universal. El schema debe ser compatible con todas las versiones activas.
Dos estrategias:
Cada entorno ejecuta build con su configuración.
Ventaja: simple para NEXT_PUBLIC_*.
Riesgo: production no usa exactamente el artefacto probado.
build immutable artifact
→ test
→ promote same artifactVentaja: mayor certeza.
Requiere separar valores runtime de build-time y controlar contenido prerenderizado.
Cachea:
No caches node_modules de forma ciega entre plataformas o versiones.
Una key debe incluir:
Un cache hit incorrecto puede publicar un bundle con variables o código antiguo.
Exige antes de merge:
Protege main y producción. Limita quién puede aprobar deployments sensibles.
Opciones:
Sustituye réplicas gradualmente. Exige compatibilidad entre versiones.
Dos entornos completos; el tráfico cambia de uno a otro. Facilita rollback, pero duplica recursos.
Un porcentaje recibe la nueva versión. Necesita métricas, segmentación y rollback automático.
Permiten separar deploy de release:
code deployed
→ feature disabled
→ enable for internal users
→ gradual rolloutUna flag necesita:
No conviertas flags permanentes en ramas imposibles de mantener.
Comprueba producción:
Usa datos de prueba seguros o transacciones reversibles.
Un rollback real incluye:
No siempre puedes revertir una migración destructiva. A veces la respuesta correcta es un forward fix.
Mide antes y después:
Un canary sin métricas solo expone usuarios gradualmente sin saber si falla.
Para DomiSys:
PR
→ lint/types/unit
→ build
→ preview con DB aislada
→ Playwright login + pedido
→ merge main
→ expand migration
→ deploy canary
→ smoke tests
→ full rolloutLas importaciones grandes y workers se prueban aparte. Un cambio de stock utiliza constraints y tests de concurrencia.
No valida flujos ni migraciones.
Riesgo de datos y side effects.
Carreras y locks.
El código anterior ya no funciona.
Publica output obsoleto.
Filtración permanente en historial.
El pipeline termina antes de comprobar el sistema real.
next build es una validación obligatoria.tsc no reemplaza next build?Monorepos con Next.js organiza varias aplicaciones y paquetes sin romper boundaries de servidor, cliente y build.