Control de código fuente
Conecte la cuenta de GitHub o GitLab en la que trabaja e implemente directamente desde una rama: en Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps o AWS Amplify — o en nuestro propio alojamiento gestionado, donde el repositorio y los archivos del sitio se mantienen sincronizados en ambas direcciones. Cada conexión muestra los privilegios que necesita, se verifica con la API del proveedor antes de guardarse y se aloja en Vault. También puede iniciar sesión con GitHub o GitLab.
Una conexión es una credencial que usted entrega a otra persona. La nuestra indica lo que necesita antes de que usted la cree, demuestra que funciona antes de guardarla y se puede revocar desde cualquiera de los dos extremos.
Antes de que cree un token, le explicamos qué debe poder hacer y por qué. Sin un alcance generalizado solo porque era más fácil de solicitar, y sin descubrir después que queríamos más de lo que requería la tarea.
Llamamos a la propia API del proveedor con su token antes de almacenarlo. Un token incorrecto, caducado o con un alcance no válido se rechaza en el formulario en lugar de ser aceptado, mostrarse como correcto y fallar en el primer despliegue real.
No en nuestro código, no en un archivo de entorno, no en un registro y no en una línea de comandos. Resuelto en el momento en que se utiliza, por la carga de trabajo que lo utiliza.
Conecte una cuenta personal y la de una organización, o dos de organizaciones. Cada sitio elige desde cuál se despliega, por lo que el repositorio de un cliente y el suyo nunca comparten credenciales.
Ocho hosts perimetrales administrados y nuestra propia flota. El destino es una propiedad del sitio, no de la conexión, por lo que el mismo repositorio puede publicar una rama en un host de Pages y otro sitio puede ejecutarse en nuestro hardware.
Ancho de banda ilimitado, uso comercial permitido y dominios apex gestionados en el mismo proveedor que normalmente aloja su zona DNS. Es la primera opción a la que recurrimos por estos motivos.
Alojamiento de Cloudflare Pages →Publique directamente desde el repositorio donde ya reside el código. Marcado en la línea Footprint-Free, ya que la infraestructura compartida de github.io constituye en sí misma una huella.
Alojamiento de GitHub Pages →GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps y AWS Amplify son destinos a los que puede dirigir un sitio, con la misma conexión y el mismo historial de despliegue.
Alojamiento de sitios estáticos →Una aplicación completa en lugar de un paquete compilado: WordPress, PHP, Node. Este es el destino que obtiene sincronización bidireccional, para que los archivos en el servidor y en la rama se mantengan sincronizados.
Alojamiento gestionado →Un sitio publicado en un host que no nos pertenece sigue consumiendo una cuota y continúa apareciendo en su panel de control con sus despliegues, su tiempo de actividad y sus datos de SEO junto a todo lo demás que usted administra.
Límites de sitios externos →El editor integrado en el navegador trabaja sobre los mismos archivos que la sincronización bidireccional envía de vuelta, por lo que una corrección rápida desde el panel de control se convierte en un commit en su rama en lugar de un cambio que nadie pueda encontrar más adelante.
El editor web →Sincronización bidireccional
Actívelo y los archivos propios del sitio se enviarán de vuelta a su rama, mientras que los commits en esa rama regresarán al sitio. Funciona en cada sitio que alojamos, en cada línea; el único requisito es que la máquina subyacente pueda ejecutar Git con sus archivos, lo cual se solicita al servidor en lugar de asumirse a partir del plan.
Usted elige qué directorio se sincroniza, ya que un cliente de WordPress desea realizar el seguimiento de su tema y no de cuarenta mil archivos del núcleo. Y permanece desactivado hasta que usted lo activa: habilitar una sincronización es una decisión sobre el repositorio de otra persona, y una migración nunca debe tomarla por usted.
Dos modos, y la diferencia radica en dónde se ejecuta la compilación. Ambos terminan en el mismo lugar: una referencia que obtenemos y publicamos, con el commit registrado junto con el despliegue.
GitHub o GitLab, en Conexiones. Los privilegios se enumeran antes de crear el token y se verifica con el proveedor antes de guardarlo.
Propietario, repositorio, rama y si publicamos un directorio o recuperamos lo que construyó su CI. Registramos el webhook de push como parte de ello.
Un push a la rama designada inicia una implementación, o bien puede implementar a petición desde la pestaña Implementar del sitio. Las compilaciones se ejecutan en segundo plano.
El historial de despliegue muestra qué se publicó y cuándo. Active la sincronización bidireccional y las ediciones que realice aquí se registrarán como commits en su rama.
Cuando algo va mal
Una conexión de repositorio que parece correcta y no recibe nada es el clásico fallo silencioso: un token con un alcance incorrecto, una entrega bloqueada en el proveedor, un webhook eliminado manualmente. Es invisible en cualquier otra pantalla, por lo que la tarjeta del repositorio lo muestra directamente: cuándo realizó el proveedor la última entrega y qué indicó.
Las entregas se someten a una comprobación de firma antes de actuar sobre ellas, utilizando el esquema propio de cada proveedor en lugar de uno que hayamos asumido aplicable a todos. Una entrega que no se verifique se rechaza y se registra, no se ignora de forma silenciosa.
Identidad
Además de con una dirección de correo electrónico y una contraseña, puede iniciar sesión en su cuenta de Zinn Digital® con GitHub, GitLab, Google o Microsoft. La capa de identidad ejecuta el protocolo de enlace; nunca vemos la contraseña de su proveedor, y la vinculación de una cuenta social a una cuenta existente de Zinn® aún debe confirmarse por correo electrónico.
Iniciar sesión con GitHub y conectar GitHub para las implementaciones son decisiones independientes y credenciales independientes. Realizar una acción no realiza la otra, y eliminar una no elimina la otra.
GitHub y GitLab. Conecte la cuenta en la que ya trabaja y podremos realizar despliegues desde sus repositorios, registrar un webhook de push en ellos y, si lo desea, sincronizar los archivos de su sitio en la otra dirección. Ambos pasan por el mismo enlace de cuenta conectada, por lo que todo lo que figura a continuación se aplica a cualquiera de los dos.
Sí, y con Google o Microsoft. Además de una dirección de correo electrónico y una contraseña, puede iniciar sesión en su cuenta de Zinn Digital® con cualquiera de las cuatro opciones. La capa de identidad gestiona el protocolo de enlace y nunca vemos la contraseña de su proveedor. Iniciar sesión con GitHub es independiente de conectar GitHub para despliegues: puede hacer cualquiera de las dos cosas, ambas o ninguna.
A Cloudflare Pages, GitHub Pages, GitLab Pages, Netlify, Vercel, Render, Azure Static Web Apps o AWS Amplify para un sitio estático o generado, o bien en nuestro propio alojamiento gestionado, donde el repositorio y los archivos del sitio se mantienen sincronizados en ambas direcciones. Usted elige el destino del sitio; la conexión con el repositorio es la misma en cualquier caso.
Cualquiera de las dos opciones. En el modo de publicación, tomamos la rama tal como está y publicamos el directorio que usted indique. En el modo CI, la canalización de su proveedor ejecuta su comando de compilación y confirma el resultado en una rama de publicación independiente, la cual luego recuperamos como cualquier otra referencia. La segunda opción mantiene su compilación en su propio CI, donde ya se encuentran sus secretos y su caché.
De forma predeterminada, sí: registramos un webhook en el repositorio y un push a la rama que haya designado inicia un despliegue. Puede desactivar esa opción y conservar el webhook, lo cual es más útil de lo que parece: la entrega se sigue registrando, por lo que puede ver cómo llegan sus pushes antes de permitirnos actuar sobre ellos.
Las ediciones realizadas en nuestro hardware se convierten en commits en su rama, y los commits de su rama regresan al sitio. Está desactivado hasta que usted lo active, porque activarlo es una decisión sobre el repositorio de otra persona y no la tomaremos por usted. Usted elige qué directorio se sincroniza; por lo general, un tema o un plugin, no cuarenta mil archivos principales de WordPress.
No se sobrescribe nada y no se envía nada. La sincronización se detiene, le informa que la rama avanzó más allá de la confirmación en la que nos basamos y le pregunta qué lado desea: conservar el repositorio o conservar el sitio. Un sitio que nunca se ha sincronizado y apunta a una rama que ya tiene confirmaciones también constituye un estado propio, y pregunta en lugar de adivinar cuál es la verdad.
Le mostramos los privilegios que necesita la conexión antes de que la cree, comprobamos el token con la propia API del proveedor al introducirlo —de modo que un token no válido o con un ámbito incorrecto nunca se almacene— y solo entonces lo escribimos en Vault. Nunca entra en contacto con nuestro código, un registro, un archivo de entorno o una línea de comandos. Revóquelo en el proveedor o elimine la conexión aquí, cuando lo desee.
La tarjeta del repositorio muestra cuándo nos entregó datos el proveedor por última vez y qué indicaba. «Nunca entregado» es el diagnóstico más útil de esa pantalla, ya que «conectado pero nunca entregado» es exactamente el aspecto que tiene un token con permisos incorrectos o una entrega bloqueada, y no se aprecia en ningún otro lugar. Cada entrega se somete a una comprobación de firma antes de que tomemos medidas al respecto.
Se ofrece y está marcado. GitHub Pages y GitLab Pages comparten la infraestructura del proveedor y los nombres de host públicos github.io y gitlab.io, lo que constituye una huella de rastreo para motores de búsqueda, justo lo que esta línea busca evitar. Para disponer de una red sin huella, implemente en un alojamiento aislado. En cualquier otro caso, Pages es de primer nivel.
Porque su nivel gratuito solo tiene licencia para uso no comercial. Deducimos un destino a partir de las cuentas que usted ha conectado donde sea seguro, y Vercel se excluye deliberadamente de esa deducción; conectar una cuenta nunca debe situar silenciosamente un sitio comercial donde su licencia no lo permita. Selecciónelo y funcionará exactamente igual que los demás.
Sí. Cada despliegue registra la confirmación que publicó, cuándo se ejecutó y cómo finalizó, y la pestaña Despliegue del sitio muestra el historial con la URL activa al lado. Los despliegues se ejecutan en segundo plano, por lo que la página se actualiza a medida que se completa la compilación en lugar de hacerle esperar frente a un indicador de carga.
Inicie una prueba de 14 días sin tarjeta, conecte GitHub o GitLab y apunte un sitio a una rama. Publique en un host perimetral o en nuestro propio alojamiento con sincronización bidireccional de archivos.
Empiece gratis