docs Despliegues de preview
Despliegues de preview
Entornos efímeros automáticos para pull requests y merge requests.
Cómo funcionan los despliegues de preview
Los despliegues de preview crean una copia aislada de tu aplicación para cada pull request (GitHub) o merge request (GitLab). Cuando se abre un PR, DeployKit construye y despliega su rama head como una aplicación independiente con su propio contenedor y URL, la vuelve a desplegar con cada nuevo push al PR y la elimina cuando el PR se cierra.
Activar los previews
- En la pestaña General de la aplicación, marca 'Auto-deploy pull requests as preview environments' y guarda
- Opcionalmente define un Base domain como example.com — cada PR recibirá entonces pr-<number>.example.com (p. ej. pr-42.example.com)
- Crea un registro DNS wildcard (*.example.com) que apunte al servidor que ejecuta la aplicación
- Asegúrate de que los eventos de PR lleguen a DeployKit: es automático con la GitHub App; en caso contrario, habilita 'Pull requests' (GitHub) o 'Merge request events' (GitLab) en el webhook del repositorio
La configuración de webhooks se explica en Webhooks & CI/CD. Las aplicaciones conectadas mediante la GitHub App reciben los eventos de PR únicamente a través de la App.
Ojo: los dominios de preview se sirven por HTTP sin cifrar — los certificados wildcard requerirían un desafío DNS. Además, los previews copian las variables de entorno del padre tal cual, así que el preview de una aplicación de producción se ejecuta con los secretos de producción y se conecta a las mismas bases de datos. Usa una aplicación de staging como padre si eso no es aceptable.
Ciclo de vida
| Evento | Resultado |
|---|---|
| PR abierto / reabierto, MR abierto / reabierto | Aplicación de preview creada y desplegada |
| Nuevos commits enviados al PR / MR | El preview existente se actualiza al nuevo head y se vuelve a desplegar |
| PR cerrado o fusionado, MR cerrado o fusionado | Contenedor detenido y aplicación de preview eliminada |
Los previews se activan solo mediante eventos de PR / MR — los eventos push normales nunca despliegan una aplicación de preview.
Relación padre-hijo
Un preview es una aplicación normal vinculada a su padre y con el nombre <app-name>-pr<number>. Cuando se crea, copia del padre:
- Repositorio, tipo de build, ruta del Dockerfile y directorio raíz
- Variables de entorno y puerto
- Servidor de destino y ajustes de health check
- Credenciales de origen — la conexión de la GitHub App si el padre tiene una (no se guarda ningún secreto en el preview); en caso contrario, el token de acceso del padre
Los volúmenes, límites de recursos, réplicas, autoescalado y los dominios del padre no se copian. Los cambios en el padre solo se aplican a los previews creados después. Los previews nunca se incluyen en una exportación de configuración.
GitHub App: comentarios en PR y estados de commit
Cuando el padre está conectado mediante la GitHub App, DeployKit mantiene un único comentario en el pull request — "Deploying preview", luego "Preview ready" con la URL (o "Preview failed") y un enlace a los logs del despliegue, y "Preview removed" cuando el PR se cierra. Los redespliegues editan ese comentario en lugar de publicar otros nuevos. Cada despliegue de preview también publica un estado de commit bajo el contexto del padre (deploykit/<parent name>), de modo que la protección de ramas ve una única comprobación estable por aplicación. Sin la App, los previews funcionan igual, pero no se informa de nada a GitHub.
Gestionar los previews
La pestaña Previews de la aplicación padre lista los previews activos con su número de PR, rama, estado, URL y último commit. Los Operator pueden eliminar un preview desde ahí; esto detiene su contenedor de inmediato, pero el siguiente push a un PR abierto lo vuelve a crear.