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

Dès qu’un projet fonctionne localement, quatre commandes suffisent pour le déployer sur un site en ligne sur l’hébergement Zinn Digital® : se connecter, lier le projet à un emplacement d’hébergement, lire la vérification préalable et déployer (push). Cet article détaille chacune d’entre elles, ce qu’elle affiche, ainsi que les commandes à utiliser par la suite : redéploiements, historique des déploiements et journaux de build.

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 lors d’une invite — elle n’est jamais acceptée directement sur la ligne de commande, afin qu’elle ne puisse pas se retrouver dans l’historique de votre shell ou dans une liste de processus. En intégration continue (CI), transmettez-la par un pipe : echo "$ZINN_API_KEY" | zinnector login --profile ci, ou définissez ZINNECTOR_TOKEN et ignorez totalement login. La clé est vérifiée avant d’être stockée, et elle est enregistrée avec les droits de fichier 600. zinnector whoami --scopes indique à quelle organisation vous êtes connecté et quelles sont les autorisations associées à la clé ; une clé de bac à sable (sandbox) est étiquetée comme telle.

Lier le projet à un emplacement

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

link inscrit l’identifiant du site dans zinnector.json et, à moins de passer l’option --no-repo, associe le dépôt distant git du projet au site sur la plateforme afin qu’un push déclenche son déploiement. Validez zinnector.json dans vos commits : un collègue qui clone le dépôt déploiera alors au même endroit sans avoir besoin d’instructions préalables. Ce fichier ne contient aucun secret.

Lire la vérification préalable

zinnector check

C’est la commande pour laquelle la CLI existe. Elle compare votre projet à l’emplacement sur lequel il est sur le point d’être déployé et affiche chaque incohérence — ainsi que chaque vérification impossible à effectuer :

• La version de PHP, avec un écart de version majeure classé comme critique (high) car il casse systématiquement un site, et un écart mineur classé à un niveau inférieur, car tout qualifier de critique pousse les utilisateurs à ignorer l’avertissement.
• Si l’emplacement peut basculer vers la version sur laquelle vous avez développé, si la version PHP de l’emplacement est en fin de vie, et si la machine a effectivement appliqué la version ou simplement reçu l’instruction de le faire.
• La taille et le nombre de fichiers de votre projet par rapport à la marge restante réelle sur l’emplacement pour le disque et les inodes — une arborescence WordPress peut se retrouver à court de fichiers tout en restant bien en deçà de son quota de disque.
• Les versions de WordPress de chaque côté, la confirmation que l’emplacement a terminé son provisionnement, et si un dépôt est connecté pour y envoyer les modifications.

La commande avertit ; elle ne bloque jamais. Chaque résultat peut être outrepassé avec zinnector push --force, car vous connaissez sur votre propre site des éléments qu’un outil de vérification ignore. Une comparaison qui n’a pas pu être effectuée est signalée comme inconnue (unknown), jamais comme réussie, et le récapitulatif indique toujours combien il y en a eu. Par défaut, la version locale de PHP est celle déclarée dans zinnector.json ; --probe démarre l’environnement d’exécution local et la mesure à la place. --strict renvoie un code de sortie non nul même sur les inconnues, ce qui est l’effet recherché pour une barrière d’intégration continue.

Déployer (push)

zinnector push

push exécute la vérification préalable, pousse vos commits, déclenche le déploiement et surveille sa progression jusqu’à son achèvement, en affichant l’état final et le commit déployé. --dry-run réalise toutes les étapes à l’exception du déploiement ; --no-wait le déclenche et se termine immédiatement ; --no-git déploie le contenu déjà présent sur la plateforme sans effectuer de push. Si le commit déployé n’est pas celui qui vient d’être poussé, la commande le signale.

En cas de problème

zinnector deploys example.com        # historique des déploiements — état, commit, déclencheur, message
zinnector logs example.com --build   # journal de build 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 "pourquoi mon déploiement échoue-t-il ?"

zinnector ai s’exécute sur la plateforme en étant rattaché à votre propre compte, ce qui lui permet d’accéder au même historique de déploiements et aux mêmes journaux. Depuis l’intérieur d’un projet, il transmet la structure du projet — noms des répertoires, versions et identifiant du site — mais jamais le contenu des fichiers.

Voir aussi

• Premiers pas · Développement local · Référence des commandes · Dépannage