El Pipeline de Build

Cuando presionas Build, un proceso en segundo plano convierte la base de datos en el sitio estático y, solo cuando todo tiene éxito, intercambia los archivos nuevos en su lugar. Nada aguas arriba muestra jamás la mitad de un build; lo primero que ve un visitante es o el sitio viejo o el nuevo completo.

Cómo inicia un build

Las ediciones de contenido nunca reconstruyen el sitio por sí solas. Un build se dispara desde el dashboard del admin, la API, un webhook o la línea de comandos. Al dispararse, el sistema reclama el build para que solo uno corra a la vez: presionar Build dos veces no iniciará un segundo; el segundo disparador simplemente reporta que hay un build en progreso. El bloqueo se libera cuando el build termina (o falla), lo que ocurra primero.

Una vez reclamado, el builder corre en segundo plano con tu base de datos y tu directorio de salida entregados explícitamente. Dependiendo de cómo se inició, el build puede ser la ejecución incremental predeterminada, un rebuild completo forzado desde cero, o uno que se salta las compuertas de seguridad para ese único build. Al terminar, tu build webhook configurado puede ser notificado para que los sistemas externos se enteren del evento.

Lo que produce el builder

El builder crea staging, un directorio output/.next separado, no live. Staging permanece junto al directorio live hasta el intercambio. Esa separación significa que toda decisión sobre si un build es seguro ocurre antes de tocar cualquier contenido live, y todas las decisiones de staging se registran con su resultado. La salida live permanece intacta frente a todo lo que escribe durante un build.

Builds incrementales y qué hace que una ejecución sea "completa"

Cada build empieza en modo incremental a menos que no lo solicites o que el builder decida que uno no es seguro. Antes de tocar staging, recorre una lista de verificación de elegibilidad:

• se solicitó incremental;
• existe una marca de tiempo del último build, y no está en el futuro;
• el directorio de salida live existe y contiene un index.html;
• hay registrada una huella digital de build del build exitoso anterior que todavía coincide con la configuración actual y las plantillas del theme (una discrepancia de huella significa un "cambio global");

Si alguna verificación falla, el build retrocede limpiamente a un rebuild completo y registra la razón. Cuando la lista pasa, staging se premonta como hardlinks desde live; los archivos de contenido se pagan en disco solo donde cambian y los archivos sin cambios van de gratis.

Luego un build re-renderiza solo el contenido sucio: elementos actualizados desde el último build, elementos cuya hora programada de publicación o despublicación cruzó desde el último build, y cualquier página/post que dependa de bloques o stacks modificados. Todo lo demás se salta y se reutiliza del render cache.

Velocidad de renderizado

El renderizado corre multi-worker por defecto según el número de CPU de la máquina (hasta 16), con un modo secuencial de un solo worker disponible. Cualquier build tiene un límite de tiempo general y un presupuesto de escritura de 2 GiB repartido entre los workers, de modo que un build con mal comportamiento nunca puede colgar el pipeline ni llenar el disco en pleno proceso.

Pasar a live: el intercambio de staging

Cuando el build termina con éxito (y la compuerta de promoción no se niega a publicarlo), staging se mueve a live:

• La disposición de producción estándar usa un symlink: el intercambio es un solo rename atómico. Cero downtime.
• Con una disposición de directorios: un rename de dos pasos introduce a lo sumo un breve instante entre los movimientos, seguro en el mismo filesystem; el directorio anterior se conserva para limpieza.
• El primer build de todos renombra el staging completado a live.

Un intercambio fallido hace rollback en lugar de publicar a medias, nunca dejando un directorio live roto.

Cuando algo sale mal en pleno proceso

Cualquier condición fatal (timeout, desbordamiento del presupuesto de escritura, errores de render o un fallo en el momento de la promoción) descarta staging y deja que la salida anterior siga sirviendo tal cual. La firma del manifest del build ocurre antes de la promoción, y si la firma o la promoción retroceden, se restaura el manifest anterior para que una firma fuera de servicio nunca reclame contenido que no está live (esta compuerta solo puede relajarse en entornos de prueba).

Lo que cada build escribe al disco

Después de cada pasada de idioma:

• La salida que ya no corresponde al contenido actual (elementos eliminados, despublicados o fuera de ventana) se elimina, de modo que las URLs obsoletas desaparecen; ya sea que staging se hubiera enlazado por hardlink desde live o se hubiera renderizado de nuevo, el conjunto conservado de rutas publicadas rige lo que permanece;
• el sitemap, el feed RSS y la página 404 por idioma;
• los enlaces internos rotos y las advertencias de HTML/a11y, todo registrado.

El build log captura todo eso (los últimos 100 builds, incluida su salida completa y sus reportes de validación), además de la marca de tiempo del último build que mantiene elegibles las ejecuciones incrementales hasta la siguiente.