Despliegue con Zinnector®: enlazar, comprobar, enviar

Una vez que un proyecto se ejecuta localmente, cuatro comandos lo llevan a un sitio activo en el alojamiento de Zinn Digital®: iniciar sesión, vincular el proyecto a un espacio de alojamiento, leer la verificación previa y realizar un envío (push). Este artículo detalla cada uno de ellos, lo que muestran y los comandos que utilizará posteriormente: nuevas implementaciones, historial de implementaciones y registros de compilación.

Iniciar sesión con una clave de API

Cree una clave en el panel de control en Configuración → Claves de API, luego:

zinnector login

La clave se escribe en un aviso; nunca se acepta en la línea de comandos, por lo que no puede terminar en el historial de su shell ni en un listado de procesos. En la integración continua (CI), introdúzcala mediante una tubería: echo "$ZINN_API_KEY" | zinnector login --profile ci, o configure ZINNECTOR_TOKEN y omita login por completo. La clave se verifica antes de almacenarse y se guarda con el modo de archivo 600. zinnector whoami --scopes muestra a qué organización ha iniciado sesión y qué permisos conlleva la clave; una clave de entorno aislado (sandbox) se etiqueta como tal.

Vincular el proyecto a un espacio

zinnector link                                   # elija un sitio de una lista
zinnector link example.com --repo acme/site --branch main

link escribe el ID del sitio en zinnector.json y, a menos que pase --no-repo, conecta el repositorio Git remoto del proyecto al sitio en la plataforma para que un envío (push) lo implemente. Confirme zinnector.json: un colega que clona el repositorio puede implementarlo en el mismo lugar sin que se lo tengan que decir. No contiene ningún secreto.

Leer la verificación previa

zinnector check

Este es el comando para el que existe la CLI. Compara su proyecto con el espacio en el que está a punto de ser implementado e imprime cada discrepancia, así como cada comparación que no pudo realizar:

• Versión de PHP, con una brecha de versión principal calificada como alta porque rompe un sitio de forma segura y una brecha menor calificada como más baja, ya que calificar todo como crítico enseña a las personas a omitir la advertencia.
• Si el espacio puede cambiar a la versión en la que compiló, si el PHP del espacio ha superado su fin de vida útil y si la máquina ha aplicado la versión o simplemente se le ha indicado.
• El recuento de archivos y tamaño de su proyecto en comparación con el espacio de disco e inodos que realmente queda en el espacio; un árbol de WordPress puede quedarse sin archivos estando muy por debajo de su límite de disco.
• Las versiones de WordPress en cada lado, si el espacio ha terminado el aprovisionamiento y si hay un repositorio conectado para realizar envíos (push).

Advierte, pero nunca bloquea. Cada hallazgo se puede anular con zinnector push --force, porque usted conoce aspectos de su propio sitio que un verificador desconoce. Una comparación que no se pudo realizar se informa como desconocida, nunca como superada, y el resumen siempre indica cuántas hubo. De forma predeterminada, la versión local de PHP es la declarada en zinnector.json; --probe arranca el entorno de ejecución local y lo mide en su lugar. --strict también sale con un código distinto de cero en los casos desconocidos, que es lo que requiere un control de integración continua (CI).

Enviar (Push)

zinnector push

push ejecuta la verificación previa, envía sus confirmaciones (commits), activa la implementación y supervisa su finalización, imprimiendo el estado final y la confirmación implementada. --dry-run hace todo excepto la implementación; --no-wait la activa y sale; --no-git implementa lo que la plataforma ya tiene sin enviar. Si la confirmación implementada no es la que se acaba de enviar, se indica.

Cuando algo sale mal

zinnector deploys example.com        # historial de implementaciones: estado, confirmación, activador, mensaje
zinnector logs example.com --build   # el registro de compilación de la implementación más reciente
zinnector logs example.com --error   # el registro de errores del sitio
zinnector deploy example.com         # volver a implementar lo que la plataforma ya tiene
zinnector ai "why is my deploy failing?"

zinnector ai se ejecuta en la plataforma en su propia cuenta, por lo que puede ver el mismo historial de implementaciones y registros. Desde el interior de un proyecto, envía la forma del proyecto (nombres de directorios, versiones y el ID del sitio) y nunca el contenido de los archivos.

Relacionado

• Primeros pasos · Desarrollo local · Referencia de comandos · Solución de problemas