Déploiement avec Zinnector® : lier, vérifier, pousser

D'un projet local à un site en ligne : connectez-vous avec une clé API, associez le projet à un emplacement d'hébergement, consultez le contrôle préalable qui compare vos versions de PHP, votre disque et WordPress à l'emplacement, et déployez — avec en plus des redéploiements, l'historique des déploiements et les journaux de build en cas de problème.

Une fois qu'un projet fonctionne en local, quatre commandes permettent de le mettre en ligne sur l'hébergement Zinn Digital® : se connecter, lier le projet à un espace d'hébergement, consulter le contrôle préalable (« pre-flight ») et déployer. Cet article détaille chacune d'elles, ce qu'elles affichent et les commandes à utiliser ensuite : rééditions de déploiement, historique des déploiements et journaux de compilation.

Se connecter avec une clé API

Créez une clé dans le tableau de bord sous Paramètres → Clés API, puis :

zinnector login

La clé est saisie à l'invite de commande — elle n'est jamais acceptée directement sur la ligne de commande, ce qui évite qu'elle ne se retrouve dans l'historique de votre shell ou dans une liste de processus. En CI, transmettez-la via un tube (pipe) : echo "$ZINN_API_KEY" | zinnector login --profile ci, ou définissez ZINNECTOR_TOKEN et omettez entièrement login. La clé est vérifiée avant d'être enregistrée, et stockée avec les droits de fichier 600. zinnector whoami --scopes indique l'organisation sur laquelle vous êtes connecté et les permissions associées à la clé ; une clé de bac à sable (« sandbox ») est identifiée comme telle.

Lier le projet à un espace

zinnector link                                   # choisir un site dans une liste
zinnector link example.com --repo acme/site --branch main

link écrit l'identifiant du site dans zinnector.json et, sauf si vous passez l'option --no-repo, connecte le dépôt Git distant du projet au site sur la plateforme afin qu'un déploiement puisse être effectué via un push. Validez (commit) zinnector.json : un collègue qui clone le dépôt pourra alors déployer au même endroit sans instruction préalable. Ce fichier ne contient aucune donnée secrète.

Consulter le contrôle préalable

zinnector check

C'est la commande pour laquelle l'interface en ligne de commande (CLI) a été conçue. Elle compare votre projet à l'espace sur le dessus duquel il va être déployé et affiche chaque non-conformité — ainsi que chaque comparaison qui n'a pas pu être effectuée :

Version de PHP, avec un écart de version majeure qualifié de élevé car il provoque immanquablement des pannes sur un site, et un écart mineur qualifié de moins critique, car tout qualifier de critique incite les utilisateurs à ignorer l'avertissement.
La capacité de l'espace à basculer vers la version avec laquelle vous avez compilé, le fait que la version PHP de l'espace soit en fin de vie, et le fait que la machine ait appliqué la version ou en ait seulement reçu l'instruction.
La taille du projet et le nombre de fichiers par rapport à l'espace disque et au quota d'inodes réellement disponibles sur l'espace — une arborescence WordPress peut saturer son nombre de fichiers bien avant d'atteindre sa limite de disque.
Les versions de WordPress de chaque côté, l'état d'achèvement du provisionnement de l'espace et la connexion d'un dépôt pour les déploiements.

Elle avertit, mais ne bloque jamais. Chaque anomalie peut être ignorée à l'aide de la commande zinnector push --force, car vous possédez des connaissances sur votre propre site qu'un outil de vérification n'a pas. Une comparaison qui n'a pas pu être réalisée est signalée comme inconnue, jamais comme validée, et le résumé indique toujours le nombre de ces éléments. Par défaut, la version PHP locale est celle déclarée dans zinnector.json ; l'option --probe démarre le moteur d'exécution local et le mesure à la place. L'option --strict renvoie un code de sortie non nul en présence d'éléments inconnus, ce qui correspond aux attentes d'une vérification CI.

Déployer (Push)

zinnector push

push exécute le contrôle préalable, envoie vos commits, déclenche le déploiement et en suit l'exécution jusqu'à son terme, en affichant le statut final ainsi que le commit déployé. L'option --dry-run effectue toutes les opérations à l'exception du déploiement ; --no-wait déclenche le déploiement et quitte immédiatement ; --no-git déploie ce qui se trouve déjà sur la plateforme sans effectuer de push. Si le commit déployé ne correspond pas à celui qui vient d'être envoyé, un message l'indique.

En cas de problème

zinnector deploys example.com        # historique des déploiements — statut, commit, déclencheur, message
zinnector logs example.com --build   # journal de compilation du déploiement le plus récent
zinnector logs example.com --error   # journal des erreurs du site
zinnector deploy example.com         # redéployer ce qui est déjà présent sur la plateforme
zinnector ai "why is my deploy failing?"

zinnector ai s'exécute sur la plateforme en lien avec votre propre compte, ce qui lui permet d'accéder au même historique de déploiement et aux mêmes journaux. Depuis l'intérieur d'un projet, cette commande transmet la structure du projet — noms de répertoires, versions et identifiant du site — à l'exclusion de tout contenu de fichier.