Bereitstellung mit Zinnector®: Verknüpfen, Prüfen, Pushen

Sobald ein Projekt lokal läuft, bringen vier Befehle es auf eine Live-Website auf dem Hosting von Zinn Digital®: Anmelden, das Projekt mit einem Hosting-Slot verknüpfen, den Pre-Flight-Check lesen und pushen. Dieser Artikel führt durch jeden einzelnen Befehl, erklärt dessen Ausgaben und stellt die Befehle vor, die Sie danach benötigen – erneute Deployments, Deployment-Historie und Build-Logs.

Mit einem API-Schlüssel anmelden

Erstellen Sie einen Schlüssel im Dashboard unter Einstellungen → API-Schlüssel, dann:

zinnector login

Der Schlüssel wird an einer Eingabeaufforderung eingegeben – er wird niemals direkt auf der Befehlszeile akzeptiert, sodass er weder in Ihrer Shell-Historie noch in einer Prozessliste landen kann. In CI übergeben Sie ihn per Pipe: echo "$ZINN_API_KEY" | zinnector login --profile ci, oder setzen Sie ZINNECTOR_TOKEN und überspringen Sie login vollständig. Der Schlüssel wird vor dem Speichern verifiziert und mit dem Dateimodus 600 abgelegt. zinnector whoami --scopes zeigt, bei welcher Organisation Sie angemeldet sind und welche Berechtigungen der Schlüssel besitzt; ein Sandbox-Schlüssel ist entsprechend gekennzeichnet.

Projekt mit einem Slot verknüpfen

zinnector link                                   # Website aus einer Liste auswählen
zinnector link example.com --repo acme/site --branch main

link schreibt die ID der Website in die Datei zinnector.json und verbindet, sofern Sie nicht --no-repo übergeben, das Git-Remote des Projekts mit der Website auf der Plattform, sodass ein Push das Deployment auslöst. Übertragen Sie die zinnector.json ins Git-Repository (Commit): Ein Kollege, der das Repository klont, deployt anschließend an denselben Ort, ohne extra instruiert werden zu müssen. Sie enthält keine Geheimnisse.

Den Pre-Flight-Check lesen

zinnector check

Dies ist der Befehl, für den das CLI existiert. Er vergleicht Ihr Projekt mit dem Slot, auf den es deployt werden soll, und gibt jede Abweichung aus – sowie jeden Vergleich, der nicht durchgeführt werden konnte:

• PHP-Version, wobei ein Versionssprung bei der Hauptversion (Major-Version) als hoch eingestuft wird, da dies zuverlässig eine Website lahmlegt, und ein Versionssprung bei einer Unterversion (Minor-Version) niedriger bewertet wird, da die Einstufung von allem als kritisch dazu führt, dass Warnungen ignoriert werden.
• Ob der Slot auf die Version wechseln kann, auf der Sie entwickelt haben, ob das PHP des Slots sein Support-Ende überschritten hat (End-of-Life) und ob die Maschine die Version tatsächlich angewendet oder lediglich den Auftrag dazu erhalten hat.
• Die Größe und Dateianzahl Ihres Projekts im Vergleich zum tatsächlich verbleibenden Speicherplatz und Inode-Spielraum auf dem Slot – einem WordPress-Verzeichnisbaum können die Inodes ausgehen, während das Festplattenlimit noch lange nicht erreicht ist.
• Die WordPress-Versionen auf beiden Seiten, ob der Slot fertig bereitgestellt ist und ob ein Repository angebunden ist, zu dem gepusht werden kann.

Er warnt; er blockiert niemals. Jeder Befund kann mit zinnector push --force überstimmt werden, da Sie Dinge über Ihre eigene Website wissen, die ein Prüfprogramm nicht wissen kann. Ein Vergleich, der nicht durchgeführt werden konnte, wird als unbekannt ausgewiesen, niemals als bestanden, und die Zusammenfassung gibt stets an, wie viele es waren. Standardmäßig ist die lokale PHP-Version diejenige, die in zinnector.json deklariert ist; --probe startet die lokale Laufzeitumgebung und misst stattdessen diese. --strict beendet den Vorgang auch bei unbekannten Werten mit einem Exit-Code ungleich null, was für eine CI-Prüfung erforderlich ist.

Push

zinnector push

push führt den Pre-Flight-Check aus, pusht Ihre Commits, stößt das Deployment an und überwacht es bis zum Abschluss, wobei der endgültige Status und der deployte Commit ausgegeben werden. --dry-run führt alles außer dem Deployment selbst aus; --no-wait stößt es an und beendet den Befehl sofort; --no-git deployt den aktuellen Stand auf der Plattform, ohne vorher zu pushen. Entspricht der deployte Commit nicht dem soeben gepushten, wird dies gemeldet.

Wenn etwas schiefgeht

zinnector deploys example.com        # Deployment-Historie – Status, Commit, Auslöser, Meldung
zinnector logs example.com --build   # das Build-Log des jüngsten Deployments
zinnector logs example.com --error   # das Fehlerprotokoll (Error-Log) der Website
zinnector deploy example.com         # den aktuellen Stand auf der Plattform erneut deployen
zinnector ai "why is my deploy failing?"

zinnector ai läuft auf der Plattform bezogen auf Ihr eigenes Konto, sodass der Befehl dieselbe Deployment-Historie und dieselben Protokolle einsehen kann. Aus einem Projekt heraus überträgt er die Struktur des Projekts – Verzeichnisnamen, Versionen und die Website-ID – und niemals Dateiinhalte.

Verwandte Themen

• Erste Schritte · Lokale Entwicklung · Befehlsreferenz · Fehlerbehebung