Implementación con Zinnector®: vincular, verificar, 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 enviar mediante push. Este artículo explica detalladamente cada uno de ellos, lo que muestran en pantalla y los comandos a los que recurrirá después: reimplementaciones, historial de despliegues 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, y luego ejecute:

zinnector login

La clave se escribe en una solicitud interactiva; nunca se acepta en la línea de comandos, por lo que no puede terminar en el historial de su shell ni en una lista de procesos. En entornos de CI, introdúzcala mediante una tubería: echo "$ZINN_API_KEY" | zinnector login --profile ci, o bien 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 en qué organización ha iniciado sesión y qué permisos tiene la clave; una clave de entorno de pruebas (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 remoto de git del proyecto al sitio en la plataforma para que un comando push lo despliegue. Confirme zinnector.json en el repositorio: así, un compañero que clone el repositorio podrá desplegar en el mismo lugar sin necesidad de indicaciones. No contiene ningún secreto.

Leer la verificación previa

zinnector check

Este es el comando para el cual existe la CLI. Compara su proyecto con el espacio en el que está a punto de desplegarse y muestra en pantalla cada discrepancia, así como cada comparación que no haya podido realizar:

• Versión de PHP, con una diferencia de versión mayor clasificada como alta debido a que interrumpe de forma casi segura un sitio, y una diferencia menor clasificada como más baja, ya que calificar todo como crítico hace que las personas ignoren las advertencias.
• Si el espacio puede cambiar a la versión sobre la que usted compiló, si la versión de PHP del espacio ha superado el final de su ciclo de vida, y si la máquina ha aplicado la versión o simplemente se le ha indicado.
• El tamaño y recuento de archivos de su proyecto en comparación con el margen real disponible de disco e inodos en el espacio: un árbol de WordPress puede quedarse sin archivos aun estando muy por debajo de su límite de disco.
• Las versiones de WordPress en cada extremo, si el espacio ha completado su aprovisionamiento, y si hay un repositorio conectado hacia el cual hacer push.

Advierte; nunca bloquea. Cada hallazgo se puede omitir con zinnector push --force, ya que usted conoce detalles sobre su propio sitio que un verificador desconoce. Una comparación que no se haya podido realizar se reporta como desconocida, nunca como superada, y el resumen siempre indica cuántas hubo. Por defecto, la versión local de PHP es la declarada en zinnector.json; --probe arranca el entorno de ejecución local y la mide en su lugar. --strict sale con un código distinto de cero también ante elementos desconocidos, que es lo requerido en un control de CI.

Enviar (push)

zinnector push

push ejecuta la verificación previa, envía sus confirmaciones mediante push, inicia el despliegue y lo supervisa hasta su finalización, mostrando en pantalla el estado definitivo y la confirmación desplegada. --dry-run realiza todo excepto el despliegue; --no-wait lo inicia y finaliza de inmediato; --no-git despliega lo que la plataforma ya posea sin hacer push. Si la confirmación desplegada no coincide con la que se acaba de enviar mediante push, se indicará expresamente.

Cuando algo sale mal

zinnector deploys example.com        # historial de despliegues: estado, confirmación, desencadenante, mensaje
zinnector logs example.com --build   # el registro de compilación del despliegue más reciente
zinnector logs example.com --error   # el registro de errores del sitio
zinnector deploy example.com         # reimplementar lo que la plataforma ya posee
zinnector ai "¿por qué falla mi despliegue?"

zinnector ai se ejecuta en la plataforma sobre su propia cuenta, por lo que puede acceder al mismo historial de despliegues y a los mismos registros. Desde el interior de un proyecto, transmite la estructura general de este (nombres de directorios, versiones y el id del sitio), y nunca el contenido de los archivos.

Temas relacionados

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