Los despliegues de vista previa dan a cada pull request su propia URL en vivo, construida a partir del código de esa rama, para que los revisores puedan recorrer el cambio real en lugar de leer un diff y adivinar. Cada vista previa se actualiza cuando se envía un nuevo commit y se elimina automáticamente cuando se cierra el pull request.
Dónde Viven Los Despliegues De Vista Previa
Abra Sitios web, haga clic en el sitio, abra el grupo Environment en el menú izquierdo del sitio y elija Vista previa. La página se titula Despliegues de vista previa.
Las vistas previas son independientes del staging. El staging es una copia del sitio de larga duración a la que se envían cambios de forma deliberada; una vista previa es un entorno de corta duración creado por cada pull request y que se descarta después. Muchos equipos usan ambos. Consulte Entornos de Staging para la otra mitad.
Configure Primero El Despliegue Git
Las vistas previas no son una función independiente. Reutilizan la clave de despliegue y el comando de compilación del sitio de producción, por lo que el sitio necesita una configuración de Git Deploy funcional antes de poder habilitar las vistas previas.
Si Git Deploy no está configurado, la página muestra Configure primero el despliegue Git y ofrece un botón Ir a despliegue Git en lugar del formulario de habilitación. Trabaje a través de Desplegar un Sitio Desde Git y luego vuelva.
Si Git Deploy está conectado pero no tiene un comando de compilación, la página de Preview muestra una advertencia. Las vistas previas asumirán que el repositorio ya está compilado, con archivos estáticos en la raíz. Eso es correcto para un sitio HTML simple e incorrecto para cualquier cosa que requiera compilación, así que configure un comando de compilación en la página de Git Deploy si su proyecto lo necesita.
Habilitación De Vistas Previas
- En la tarjeta Habilitar despliegues de vista previa, escriba el repositorio en formato
owner/repo. No una URL, no una dirección SSH: solo los dos segmentos, por ejemploacme/marketing-site. - Haga clic en Enable.
Cualquier valor que no coincida con owner/name se rechaza con El repositorio debe estar en formato propietario/nombre.
Inmediatamente después de habilitar, KPanel muestra el secreto de firma del webhook en una tarjeta encabezada Copie su secreto de webhook ahora, con una advertencia de que no volverá a verlo.
Copie el secreto antes de salir de la página. Se genera una sola vez y no se puede recuperar después. Si lo pierde, la solución es regenerarlo, lo cual invalida el anterior y, de todos modos, implica actualizar el webhook de su repositorio.
Agregar El Webhook A Su Repositorio
La tarjeta configurada muestra una URL del webhook para pegar en la configuración de su repositorio, en Webhooks. Configúrelo con:
- URL de carga: la URL del webhook que se muestra en la página.
- Secreto: el valor que acaba de copiar.
- Tipo de contenido: JSON.
- Eventos: eventos de pull request, además de pushes, para que los nuevos commits en un pull request abierto reconstruyan la vista previa.
Una vez hecho esto, abrir un pull request genera una vista previa en pocos minutos. Un trabajo en segundo plano comprueba si hay nuevo trabajo de vista previa cada minuto, así que no es necesario pulsar nada en KPanel.
URLs De Vista Previa
Cada vista previa obtiene su propio nombre de host con la forma pr-<pull-request-number>-<site-id>.kapsulecloud.app, cubierto por un certificado comodín, de modo que se sirve por HTTPS sin ningún paso de certificado propio.
La forma fiable de abrir una es el botón Open en la fila de la vista previa dentro de Previews recientes, que lleva la URL exacta que se aprovisionó para esa compilación. Pegue ese enlace en el pull request para que los revisores no tengan que buscar KPanel en absoluto.
Lectura De La Lista De Previews Recientes
La sección Previews recientes enumera las vistas previas más recientes, empezando por la más nueva. Cada fila muestra el número y el título del pull request, la rama, el commit y un estado:
| Estado | Significado |
|---|---|
| BUILDING | Clonando y compilando ahora |
| LIVE | Sirviendo en su URL de vista previa |
| FAILED | La compilación falló; expanda el registro para ver por qué |
| DESTROYED | Limpiado, normalmente porque el pull request se cerró |
Haga clic en Alternar registro de compilación en una fila para expandir su salida de compilación en línea. Ese registro es el primer lugar donde mirar cuando falla una vista previa, y es la misma salida que produciría su compilación localmente.
Si la lista está vacía, la página lo indica: abra un pull request en el repositorio y se compilará una vista previa en pocos minutos.
Rotación Del Secreto Del Webhook
Haga clic en Regenerar secreto en la tarjeta configurada. KPanel le pide que confirme, y es explícito en que el secreto actual deja de funcionar de inmediato y que deberá actualizarlo después en la configuración del webhook de su repositorio.
El nuevo secreto se muestra una sola vez, en la misma tarjeta de un solo uso que antes. Cópielo y luego actualice el webhook en su repositorio. Entre esos dos momentos, las entregas de webhook entrantes se rechazan, así que realice los dos pasos uno justo después del otro.
Regenere el secreto cuando alguien con acceso de administrador al repositorio se marche, o si el secreto se ha pegado alguna vez en algún lugar donde no debería haber estado, como un canal de chat compartido o un ticket.
Desactivación De Las Vistas Previas
Haga clic en Disable. La configuración se desactiva y se borra el secreto almacenado. Las vistas previas existentes dejan de reconstruirse.
Ordene también eliminando el webhook en su repositorio. Empezará a fallar en lugar de hacer algo perjudicial, pero un webhook que devuelve errores para siempre es ruido en el registro de entregas de su repositorio.
Costes Y Mantenimiento
Las vistas previas compilan y sirven código real, por lo que usan los mismos recursos que cualquier otro despliegue en el sitio. Dos hábitos mantienen eso bajo control:
- Cierre los pull requests en los que ya no esté trabajando. Un pull request cerrado tiene su vista previa limpiada automáticamente.
- No apunte las vistas previas a credenciales de producción. Déles claves de prueba a través de la pestaña Secrets, en el entorno preview, que existe precisamente para que la configuración de vista previa y producción no puedan confundirse.
Una URL de vista previa no es privada. Es un nombre de host real, de acceso público, con un certificado válido, y cualquiera que tenga el enlace puede abrirlo. No use una vista previa para revisar nada que contenga datos reales de clientes, y no alimente entornos de vista previa a partir de un volcado de la base de datos de producción.
Solución De Problemas
No se compila nada cuando se abre un pull request. Compruebe las entregas recientes del webhook en su repositorio. Un 401 o 403 significa que el secreto no coincide, así que regénerelo y actualice ambos extremos. Ninguna entrega en absoluto significa que el webhook no está suscrito a eventos de pull request.
La vista previa se compila pero muestra un listado de directorio o un 404. El directorio de salida en la página de Git Deploy no coincide con el lugar donde su compilación realmente escribe. Las vistas previas heredan esa configuración de producción.
La compilación falla solo en la vista previa. La causa más común es una dependencia o una variable de entorno que existe en producción pero que nunca se agregó al entorno de vista previa. Compruebe la pestaña preview en la página de Secrets.
Una URL de vista previa deja de funcionar. Observe el estado en su fila. DESTROYED significa que el pull request se cerró y el entorno fue reclamado, que es el comportamiento previsto.
Hacia Dónde Ir Después
- Desplegar un Sitio Desde Git, la configuración previa necesaria.
- Almacenamiento De Secretos De Aplicación Para Un Sitio para credenciales por entorno.
- Entornos de Staging para una copia persistente de preproducción.