Deployment mit Zinnector®: Verknüpfen, prüfen, veröffentlichen

Von einem lokalen Projekt zu einer Live-Website: Melden Sie sich mit einem API-Key an, verknüpfen Sie das Projekt mit einem Hosting-Slot, lesen Sie den Pre-Flight, der Ihre PHP-, Festplatten- und WordPress-Daten mit dem Slot vergleicht, und führen Sie einen Push aus – inklusive neuer Bereitstellungen, Bereitstellungshistorie und Build-Protokollen, falls einmal etwas schiefgeht.

Sobald ein Projekt lokal läuft, bringen vier Befehle es auf eine Live-Website im Hosting von Zinn Digital®: Anmelden, das Projekt mit einem Hosting-Slot verknüpfen, den Pre-Flight lesen und Pushen. Dieser Artikel geht auf jeden einzelnen Befehl ein, erläutert dessen Ausgabe und zeigt die Befehle, die Sie danach verwenden – Neudistributionen, den Deployment-Verlauf und Build-Protokolle.

Mit einem API-Schlüssel anmelden

Erstellen Sie im Dashboard unter Einstellungen → API-Schlüssel einen Schlüssel und führen Sie dann Folgendes aus:

zinnector login

Der Schlüssel wird an einer Eingabeaufforderung eingegeben – er wird niemals in der Befehlszeile akzeptiert, sodass er weder in Ihrem Shell-Verlauf noch in einer Prozessliste landen kann. In CI-Umgebungen leiten Sie ihn per Pipe weiter: echo "$ZINN_API_KEY" | zinnector login --profile ci oder legen ZINNECTOR_TOKEN fest und überspringen login gänzlich. Der Schlüssel wird vor dem Speichern verifiziert und mit der Dateiberechtigungsstufe 600 gespeichert. zinnector whoami --scopes zeigt an, bei welcher Organisation Sie angemeldet sind und über welche Berechtigungen der Schlüssel verfügt; ein Sandbox-Schlüssel wird als solcher gekennzeichnet.

Das Projekt mit einem Slot verknüpfen

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

link schreibt die ID der Website in zinnector.json und verbindet – sofern Sie nicht --no-repo übergeben – das Git-Remote des Projekts mit der Website auf der Plattform, sodass ein Push diese bereitstellt. Fügen Sie zinnector.json zu den Commits hinzu: Ein Kollege, der das Repository klont, stellt die Website anschließend am selben Ort bereit, ohne dass dies extra angewiesen werden muss. Die Datei enthält keinerlei vertrauliche Daten.

Den Pre-Flight lesen

zinnector check

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

PHP-Version, wobei eine Diskrepanz bei der Hauptversion als schwerwiegend eingestuft wird, da dies zuverlässig zu einem Ausfall der Website führt, und eine Diskrepanz bei der Nebenversion niedriger eingestuft wird, da die Einstufung sämtlicher Probleme als kritisch dazu führt, dass Warnungen ignoriert werden.
Ob der Slot auf die Version wechseln kann, mit der Sie gebaut haben, ob sich die PHP-Version des Slot bereits am Ende ihres Lebenszyklus befindet und ob das System die Version übernommen hat oder dies nur angewiesen wurde.
Die Größe und Dateianzahl Ihres Projekts im Vergleich zum tatsächlich auf dem Slot verbleibenden Speicherplatz und Inode-Kontingent – eine WordPress-Struktur kann keine Dateien mehr speichern, obwohl sie sich deutlich unterhalb ihres Speicherlimits befindet.
Die WordPress-Versionen auf beiden Seiten, ob der Slot das Provisioning abgeschlossen hat und ob ein Repository für den Push verbunden ist.

Es warnt, blockiert jedoch niemals. Jedes Ergebnis kann mit zinnector push --force übergangen werden, da Sie Dinge über Ihre eigene Website wissen, die eine Überprüfung nicht erfassen kann. Ein Vergleich, der nicht durchgeführt werden konnte, wird als unbekannt gemeldet (niemals als erfolgreich bestanden), und in der Zusammenfassung wird stets ausgegeben, wie viele es davon gab. Standardmäßig ist die lokale PHP-Version diejenige, die in zinnector.json deklariert ist; --probe startet die lokale Laufzeitumgebung und misst stattdessen den tatsächlichen Wert. Mit --strict wird bei unbekannten Werten ebenfalls ein Exit-Code ungleich null ausgegeben, was von einer CI-Prüfstufe erwartet wird.

Pushen

zinnector push

push führt den Pre-Flight aus, überträgt Ihre Commits, löst das Deployment aus, überwacht es bis zum Abschluss und gibt den finalen Status sowie den bereitgestellten Commit aus. --dry-run führt sämtliche Schritte mit Ausnahme des Deployments aus; --no-wait löst es aus und beendet den Prozess; --no-git stellt das bereit, was sich bereits auf der Plattform befindet, ohne einen Push auszuführen. Weicht der bereitgestellte Commit von dem ab, der soeben per Push übertragen wurde, wird dies entsprechend ausgegeben.

Wenn etwas schiefgeht

zinnector deploys example.com        # Deployment-Verlauf – Status, Commit, Auslöser, Meldung
zinnector logs example.com --build   # das Build-Protokoll des jüngsten Deployments
zinnector logs example.com --error   # das Fehlerprotokoll der Website
zinnector deploy example.com         # erneutes Bereitstellen des bereits auf der Plattform befindlichen Stands
zinnector ai "why is my deploy failing?"

zinnector ai wird auf der Plattform im Kontext Ihres eigenen Kontos ausgeführt, sodass Zugriff auf denselben Deployment-Verlauf und dieselben Protokolle besteht. Innerhalb eines Projekts werden lediglich die Struktur des Projekts – Verzeichnisnamen, Versionen und die Website-ID – und niemals Dateiinhalt übertragen.