Automatisches Deployment von GitHub, GitLab oder Bitbucket mit sofortigem Rollback

Das automatische Deployment verbindet Ihre Repositorys bei GitHub, GitLab, Bitbucket, Gitea/Forgejo oder auf jedem per HTTPS erreichbaren Git-Server mit Ihrem Hosting und bereitet eine neue Version des Codes vor, bevor es sie über einen symbolischen Link aktiviert. Sie können schnell zu einer aufbewahrten Version zurückkehren. Ob die Anwendung durchgehend funktioniert, hängt aber auch von ihren Migrationen, freigegebenen Dateien und Skripten ab; der Wechsel des Codes setzt diese Daten nicht zurück.

Enthält Ihr Repository React, Vue oder ein anderes Frontend, das in HTML-, CSS- und JavaScript-Dateien mündet, lesen Sie auch, wie Sie eine statische Website mit externer API hosten.

Sie öffnen das Tool im Kundenbereich unter Hosting → Ihren Dienst auswählen → Deploy+.

Ein Repository verbinden

Klicken Sie auf Repository verbinden. Die Einrichtung erfolgt in drei Schritten auf derselben Karte; solange ein Schritt nicht erledigt ist, geht es nicht zum nächsten, sodass Fehler dort erscheinen, wo man sie behebt.

Schritt 1 · Repository

• Anbieter: GitHub, GitLab, Bitbucket, Gitea/Forgejo oder „Anderer Git-Server“. GitLab und Gitea unterstützen selbst gehostete Installationen: Es genügt, dass die URL auf Ihren Server zeigt.
• Repository-URL: die https://-Adresse des Repositorys, dieselbe, mit der Sie es klonen würden. SSH-URLs (git@servidor:cuenta/repo.git) funktionieren nicht: Das Deployment klont per HTTPS mit Token.
• Zugriffstoken: wird verschlüsselt gespeichert und dient dazu, auf das Repository zuzugreifen und, wo nötig, die API des Anbieters abzufragen und den Webhook zu verwalten. Bei einem öffentlichen Repository können Sie es leer lassen. Das Aufklappmenü „So erstellen Sie das Token bei jedem Anbieter“ zeigt für den gewählten Anbieter, wo Sie es erstellen und welche Berechtigungen es genau braucht.
• Zugang prüfen: fragt die API des Anbieters ab und antwortet mit dem Repository, ob es öffentlich oder privat ist, dem Standard-Branch und der Liste der Branches. Fehlt dem Token eine Berechtigung, steht das hier und nicht mitten im ersten Deployment.
• Branch, der deployt wird: wird aus dem Aufklappmenü mit den aus dem Repository gelesenen Branches gewählt.

Berechtigungen, die jeder Anbieter verlangt:

Bei Anderer Git-Server gibt es keine API zum Abfragen: Der Zugang wird nicht geprüft, die Branches werden nicht gelesen, und der Webhook kann nicht automatisch angelegt werden. Das Deployment bei jedem Push erfolgt, indem Ihre eigene Integration die manuelle URL aufruft. Zusätzlich werden Sie nach dem Benutzernamen gefragt, mit dem Ihr Server die HTTPS-Authentifizierung akzeptiert (sehen Sie nach, welchen Benutzer Ihr Anbieter verlangt).

Erstellen Sie das Token immer mit der kürzesten Laufzeit, die für Sie passt, widerrufen Sie es, wenn Sie das Deployment löschen, und erneuern Sie es vor dem Ablauf, ohne seine Berechtigungen zu erweitern. Verwenden Sie bei GitHub kein klassisches Token mit dem globalen Scope repo.

Schritt 2 · Ziel und Projekt

• Projekttyp: Wählen Sie Laravel, Symfony, WordPress, PHP/Composer, Kompiliertes Frontend, Statisches HTML oder Anderes Projekt. Das Profil schlägt ein Web-Stammverzeichnis, freigegebene Dateien und ein passendes Skript vor, die Sie vor dem Speichern prüfen können.
• Repository-Name: eine Bezeichnung, um es in der Liste wiederzuerkennen; wird automatisch mit dem Namen des Repositorys ausgefüllt.
• Veröffentlichungsordner: public_html für die Hauptdomain, subdominios/app für eine Subdomain. Unter dem Feld sehen Sie den vollständigen Zielpfad und was dieser Ordner ausliefert.
• Web-Stammverzeichnis im Repository: Das Profil setzt es auf public für Laravel und Symfony, auf dist für ein kompiliertes Frontend oder auf das Stammverzeichnis für Projekte ohne öffentlichen Unterordner. Ändern Sie es, wenn Ihr Build ein anderes Verzeichnis erzeugt, etwa build oder out.
• Freigegebene Dateien und Ordner: ein Pfad pro Zeile; sie werden außerhalb jeder Version gespeichert und in alle verlinkt.
• Aufbewahrte Versionen: wie viele frühere Releases für ein Zurückkehren aufbewahrt werden. Standardmäßig 5.

Schritt 3 · Automatisierung

• Bei Push deployen: Hat der Anbieter eine API und darf das Token Webhooks verwalten, legen wir den Webhook beim Verbinden des Repositorys selbst an. Andernfalls zeigt die Übersicht Ihnen die URL (und das Geheimnis, wenn Sie eine Signatur verlangen), um sie in den Webhook-Einstellungen des Anbieters einzufügen.
• Signatur jeder Benachrichtigung prüfen: Es werden nur Benachrichtigungen akzeptiert, die der Anbieter signiert hat. GitHub und Bitbucket signieren mit HMAC-SHA256, Gitea ebenfalls, und GitLab sendet das Geheimnis im Header X-Gitlab-Token.
• Den Laravel-Scheduler einplanen: ist bei einem Laravel-Projekt angehakt. Wenn das erste Deployment erfolgreich abgeschlossen ist, fügen wir Ihren Cron-Jobs php artisan schedule:run jede Minute im current der Anwendung hinzu, mit dem absoluten Pfad der PHP-Version, die Ihr Konto gewählt hat. Das erklären wir unter Der Laravel-Scheduler.
• Deployment-Skript: Prüfen Sie das vom Profil vorgeschlagene oder wählen Sie Nur Assets mit Node kompilieren, PHP mit Composer oder Kein Skript. Sie können auch eigene Befehle schreiben; gespeichert wird, was im Textfeld steht.

Der Schritt endet mit einer Zusammenfassung Ihrer Auswahl und der Schaltfläche Repository verbinden.

Ein Deployment ausführen

Wenn Sie auf Repository verbinden klicken, prüft das System den SSH-Zugang (und aktiviert ihn bei Bedarf automatisch), validiert die Konfiguration und speichert das Repository. Es erscheint nun in der Liste mit der Schaltfläche Jetzt deployen.

Klicken Sie für das erste Deployment auf Jetzt deployen. Der Pfad muss leer sein: Enthält er eine frühere Website, fordert Sie das System auf, eine Kopie anzulegen und diesen Inhalt zu entfernen, bevor es weitergeht.

Während des Vorgangs zeigt die Fortschrittskarte die Schritte untereinander (Verbindung, Klonen, freigegebene Dateien, Skript, Aktivierung und Aufräumen), mit der Dauer jedes Schritts und der Gesamtzeit. Die Konsole ist hinter Konsole anzeigen eingeklappt: Schlägt etwas fehl, öffnet sich der fehlerhafte Schritt von selbst mit den letzten Zeilen der Ausgabe, einer Erklärung, was passiert ist, und Schaltflächen zum erneuten Versuchen oder zum Korrigieren von Token oder URL. Tritt der Fehler vor der Aktivierung des neuen Codes auf, bleibt die vorherige Version veröffentlicht. Prüfen Sie den fehlgeschlagenen Schritt: Die Skripte können freigegebene Daten geändert haben, und bei einem Fehler nach der Aktivierung müssen Sie prüfen, welche Version die Website ausliefert.

Die Details des Repositorys zeigen außerdem eine URL für das manuelle Deployment für externe Integrationen. Diese URL enthält ein Geheimnis, mit dem sich Deployments starten lassen: Veröffentlichen Sie sie nicht, nehmen Sie sie nicht in Screenshots oder Logs auf und erzeugen Sie sie sofort neu, wenn sie offengelegt wurde.

Eigene Skripte

Die meisten Projekte müssen während des Deployments Befehle ausführen, um Abhängigkeiten zu installieren oder Assets zu kompilieren. Den Editor öffnen Sie über das Menü des Repositorys (drei Punkte) → Skript bearbeiten.

Wie das Skript ausgeführt wird

Der Editor bietet zwei Modi, zwischen denen Sie jederzeit wechseln können, ohne dass sich der Text des Skripts ändert:

• Ein Befehl pro Zeile: der bisherige Modus, den alle Repositorys behalten, die vor Einführung der Option verbunden wurden. Jede Zeile wird separat ausgeführt, in einer eigenen Shell und aus dem Ordner der neuen Version, sodass ein cd oder export nicht in die nächste Zeile wirkt. Schlägt ein Befehl fehl, werden die folgenden nicht ausgeführt.
• Vollständiges Bash-Skript: Das ganze Skript läuft in einer einzigen Bash-Shell von oben nach unten, mit Bedingungen, Schleifen, Funktionen und Variablen, die von einer Zeile zur nächsten erhalten bleiben. Es stoppt beim ersten fehlgeschlagenen Befehl, wie mit set -e, und das Log nennt diesen Befehl so, wie er geschrieben ist. Ein Fehler mitten in einer Pipe (comando | otro) stoppt es nicht, es sei denn, Sie beginnen das Skript mit set -o pipefail. Beim Speichern prüft der Editor, ob Bash das Skript versteht.

Im Bash-Modus wird NVM einmal geladen und gilt für den Rest des Skripts:

composer install --no-dev --optimize-autoloader --no-interaction

if [[ "$HOSTSUAR_DEPLOY_TRIGGER" == "webhook" ]]; then
    php artisan migrate --force
fi

export NVM_DIR="$HOME/.nvm"
. "$NVM_DIR/nvm.sh"
npm ci --include=dev
npm run build

Ein exit 0 beendet das Skript vorzeitig, ohne das Deployment als fehlgeschlagen zu werten. Ein Befehl, der auf eine Tastatureingabe wartet, bekommt keine: Fügen Sie die Option hinzu, die ihn nicht interaktiv macht, etwa --no-interaction bei Composer.

Variablen für das Skript

Unter dem Skript gibt es zwei voneinander unabhängige Schalter. Sie funktionieren in beiden Modi.

Deployment-Daten stellt dem Skript diese Variablen bereit. Bei Repositorys, die seit dem 23. September 2026 verbunden wurden, ist er aktiviert; bei älteren ist er ausgeschaltet, bis Sie ihn aktivieren.

Keine davon enthält Geheimnisse: weder das Git-Token noch das Webhook-Geheimnis. Ein Rollback, das eine gelöschte Version neu aufbauen muss, führt das Skript mit HOSTSUAR_DEPLOY_TRIGGER=rollback und dem Commit dieser Version aus.

Variablen der .env übergibt die Schlüssel der freigegebenen .env an das Skript und an alles, was es startet, etwa ein bash scripts/deploy.sh, Composer, npm oder Artisan. Die Datei wird nicht verändert, und die Variablen existieren nur während des Deployments:

• Sie werden mit vlucas/phpdotenv gelesen, demselben Parser, den Laravel verwendet, mit seinen Regeln für Anführungszeichen, Kommentare und die Interpolation ${VARIABLE}. Würde Laravel die Datei nicht akzeptieren, stoppt das Deployment vor dem Skript, und das Log erklärt das, ohne den Inhalt zu zeigen.
• Ein Schlüssel, der in der Umgebung des Kontos bereits existiert, etwa PATH oder HOME, behält seinen Wert, genau wie in Laravel.
• Nicht übergeben werden Schlüssel, die Bash nicht als Variable akzeptiert (mit Punkt oder Bindestrich oder Namen der Shell selbst wie IFS oder UID), und solche, die mit HOSTSUAR_DEPLOY_ beginnen. Das Log nennt, welche ausgelassen wurden.
• Die Werte werden über eine temporäre Datei übergeben, die nur Ihr Konto lesen kann und die am Ende gelöscht wird, auch wenn das Deployment fehlschlägt. Sie erscheinen nie in der Befehlszeile. Bricht der Vorgang abrupt mittendrin ab, wird die Datei nach zwei Stunden bei einem späteren Deployment mit aktivierter Option gelöscht.
• Gibt es keine .env, läuft das Skript ohne diese Variablen, und das Log weist darauf hin.

Beachten Sie vor dem Aktivieren zwei Auswirkungen:

• Was das Skript ausgibt, wird im Verlauf gespeichert. Deploy+ verbirgt Werte, deren Schlüssel nach Geheimnissen aussehen (unter anderem mit PASSWORD, SECRET, TOKEN oder KEY), und Adressen mit Benutzer und Passwort wie mysql://usuario:clave@host, kann aber nicht alle erkennen, und Werte mit weniger als 8 Zeichen werden nicht verborgen. Geben Sie keine Geheimnisse aus und aktivieren Sie nicht set -x, das jeden Befehl mit seinen Werten anzeigt.
• Auch das Framework sieht die Variablen. Kommt in Laravel APP_ENV als Variable an (aus der .env oder aus Ihrem eigenen Konto) und enthält das Repository eine .env.production (oder die Datei, die zu ihrem Wert gehört), liest Laravel während des Skripts diese Datei statt der .env, auch bei php artisan config:cache. Schlüssel, die bereits als Variablen ankommen, ersetzt es aber nicht: Steht in der .env APP_DEBUG=true und in der .env.production APP_DEBUG=false, bleibt es bei true. Das Log weist darauf hin, wenn es diese Datei erkennt. In Symfony haben Systemvariablen Vorrang vor .env.local und .env.prod.local: Wenn Sie diese Dateien verwenden, um die .env zu überschreiben, lassen Sie diese Option ausgeschaltet.

Beispiele

Beispiele für Projekte, die ihre Lock-Dateien (composer.lock oder package-lock.json) und die genannten Build-Skripte enthalten. npm ci --include=dev installiert auch die Build-Werkzeuge; dafür muss die Lock-Datei synchron sein. Prüfen Sie vorher, welche PHP- und Node-Versionen das Projekt braucht:

Laravel mit Composer und npm:

composer install --no-dev --optimize-autoloader
php artisan config:cache
php artisan route:cache
php artisan view:cache
export NVM_DIR="$HOME/.nvm" && . "$NVM_DIR/nvm.sh" && npm ci --include=dev
export NVM_DIR="$HOME/.nvm" && . "$NVM_DIR/nvm.sh" && npm run build

Fügen Sie kein php artisan queue:restart hinzu: Das Skript läuft, bevor die Version aktiviert wird, und Deploy+ startet Ihre Worker danach ohnehin neu. Das erklären wir unter Queue-Worker und dauerhafte Prozesse.

WordPress mit npm:

export NVM_DIR="$HOME/.nvm" && . "$NVM_DIR/nvm.sh" && npm ci --include=dev
export NVM_DIR="$HOME/.nvm" && . "$NVM_DIR/nvm.sh" && npm run build

Einfaches PHP-Projekt:

composer install --no-dev

Die Skripte laufen in der neuen Version, bevor sie aktiviert wird; ein Fehler im Skript verhindert also, dass dieser neue Code aktiviert wird. Ihre Operationen an einer Datenbank, externen Diensten oder freigegebenen Pfaden können aber die veröffentlichte Website betreffen und werden nicht automatisch rückgängig gemacht. Der Editor speichert kein Skript, das gesperrte Befehle wie sudo, chmod 777, dd, mkfs, fdisk, shutdown, reboot oder halt verwendet: Er nennt die Zeile, damit Sie sie entfernen. pkill und kill sind erlaubt, da sie nur die Prozesse Ihres Kontos betreffen. Um Queue-Worker neu zu starten, brauchen Sie sie nicht: php artisan queue:restart sorgt dafür, dass sie den laufenden Job ordnungsgemäß beenden, bevor sie sich beenden. Bis zum 23. September 2026 wurden diese Zeilen beim Speichern ohne Hinweis entfernt, ebenso andere, die diese Buchstaben nur innerhalb eines Wortes enthielten, etwa git add. Wenn Sie Ihr Skript vor diesem Datum gespeichert haben, öffnen Sie es und prüfen Sie, ob alle vorgesehenen Zeilen noch vorhanden sind.

Deploy+ prüft Node.js, bevor diese Befehle ausgeführt werden, und installiert es automatisch, wenn es fehlt. Verlangt das Projekt eine bestimmte Version, wählen Sie sie vorher im Paketmanager.

Freigegebene Dateien und .env

Die Datei .env bleibt zwischen Deployments automatisch erhalten. Um weitere Dateien oder Ordner freizugeben, öffnen Sie Freigegebene Dateien (Menü → Freigegebene Dateien) und geben die relativen Pfade an, einen pro Zeile.

Zum Beispiel:

storage/app
storage/logs
uploads

Die freigegebenen Dateien werden in ~/deploy/nombre-repo/shared/ gespeichert und automatisch in jede Version verlinkt. Die .env können Sie direkt über das Menü → .env bearbeiten ändern. Die freigegebene Datei wird sofort aktualisiert, und bei Laravel-Anwendungen werden die Caches automatisch geleert. Bei einem kompilierten Frontend ändern sich Variablen, die in das JavaScript eingebaut werden, erst mit einem neuen Build; starten Sie danach also ein weiteres Deployment.

Die Option für Umgebungsvariablen in Deploy+ verwaltet diese .env-Datei; sie ist kein globaler Variablenspeicher des Servers und exportiert ihre Werte nicht automatisch an alle Prozesse. Jede Anwendung muss die Datei mit dem Mechanismus ihres Frameworks oder einer entsprechenden Bibliothek laden. Laravel verwendet zum Beispiel vlucas/phpdotenv. Web-PHP oder ein Cron-Job können die Werte lesen, wenn sie die Anwendung oder ihren Konfigurationslader starten; ein eigenständiger Befehl, der die .env nicht lädt, erhält sie nicht als Systemvariablen. Die Ausnahme ist das Deployment-Skript: Mit eingeschaltetem Schalter Variablen der .env erhalten seine Befehle die Werte als Variablen (siehe Abschnitt Variablen für das Skript).

LiteSpeed und der PHP Selector bieten innerhalb des Kontos keinen Secret-Manager, den Web-PHP, Cron und Deploy+ gemeinsam nutzen. Variablen, die der Serveradministrator dem Web-PHP bereitstellt, gelangen dadurch nicht in die beiden anderen Kontexte. Deploy+ bietet derzeit auch keine eingebaute Integration mit externen Managern wie 1Password: Verwendet die Anwendung einen, muss sie die Abfrage selbst umsetzen und die Werte an jeden Prozess übergeben.

Die Variablen werden innerhalb jedes Prozesses geladen und nicht von selbst an andere Anwendungen weitergegeben. Alle Anwendungen eines cPanel-Kontos laufen jedoch mit demselben Benutzer: Ein Prozess dieses Kontos könnte die .env lesen, wenn er ihren Ort kennt. Liegt sie außerhalb des Web-Stammverzeichnisses, lässt sie sich nicht per HTTP herunterladen, das schafft aber keine Sicherheitsgrenze zwischen den Anwendungen des Kontos. Für vollständige Isolation brauchen Sie einen separaten Hosting-Dienst mit einem anderen Systembenutzer.

Um die drei Kontexte zu prüfen, können Sie zuerst eine Variable ohne geheime Information verwenden. Der Test muss Web-PHP, Cron und den Deployment-Befehl denselben Lader starten lassen; echte Zugangsdaten müssen Sie dafür nicht ändern und den Server nicht neu starten. Lädt ein Kontext die Datei nicht, beschreibt das Fehlen der Variable diesen Prozess, nicht einen Verlust der freigegebenen .env.

Bereiten Sie persistente Inhalte vor, bevor Sie veröffentlichen. Ein vorhandener freigegebener Pfad hat Vorrang vor der Datei, die mit dem Repository kommt; ihn in die Liste aufzunehmen, führt beide Versionen nicht automatisch zusammen. Legen Sie keinen Code, den Sie mit jedem Deployment aktualisieren möchten, in einen freigegebenen Ordner. Geben Sie node_modules nicht frei, wenn Sie npm ci verwenden: Dieser Befehl löscht den Ordner und baut ihn neu auf, was andere Releases betreffen könnte, die darauf verweisen. Sichern Sie eine Kopie, bevor Sie diese Konfiguration ändern.

Die freigegebene .env betrifft die aktive Anwendung. Behalten Sie bei einer bestehenden Laravel-Installation ihren APP_KEY bei; ihn zu ändern gehört nicht zu einem normalen Deployment. Legen Sie keine Geheimnisse in Variablen ab, die ein Frontend in das öffentliche JavaScript kompiliert. Bewahren Sie vor dem Bearbeiten der .env eine private Kopie auf: Das Rollback ändert den veröffentlichten Code, stellt aber keine frühere Version dieser Datei wieder her.

Verlauf und Rollback

Der Deployment-Verlauf wird über das Menü des Repositorys geöffnet und erscheint in dessen eigener Übersicht als Tabelle mit Datum, Auslöser (Manuell, Push, Rollback oder Geplant), deploytem Commit mit Nachricht und Autor, Dauer und Status. Der Filter Alle / Fehlgeschlagen zeigt nur, was schiefgegangen ist. Klicken Sie auf Details ansehen, um die Schritte mit ihren Zeiten und die vollständige Konsolenausgabe aufzuklappen.

Für ein Rollback auf eine frühere Version suchen Sie das Deployment im Verlauf und wählen in seinem Menü Zu dieser Version zurückkehren; vor jeder Änderung wird eine Bestätigung verlangt. Das System prüft, ob die Version existiert, ändert den symbolischen Link so, dass er auf sie zeigt, und aktualisiert das Verzeichnis. Ist das Release noch vorhanden, muss der Code nicht erneut geklont werden, und der Wechsel geht meist schnell. Prüfen Sie danach, ob die wichtigsten Seiten und Vorgänge mit den aktuellen Daten funktionieren.

Ist die Version nicht mehr auf dem Server, weil die automatische Bereinigung sie gelöscht hat, baut das System sie neu auf: Es klont das Repository und fordert bei Ihrem Git-Anbieter genau diesen Commit an. Das dauert länger als ein normales Rollback und setzt voraus, dass der Anbieter den Commit bereitstellt und die Zugangsdaten noch gültig sind. Dabei wird auch das konfigurierte Skript erneut ausgeführt, das weiterhin mit diesem Code und seinen Abhängigkeiten kompatibel sein muss.

Die Rückkehr zu einer Version, die noch auf dem Server liegt, führt das Skript nicht aus. Die dauerhaften Prozesse der Anwendung wechseln aber auf die wiederhergestellte Version: Deploy+ startet sie am Ende neu, genau wie nach einem Deployment, und das Log dieses Rollbacks zeigt, in welchem Zustand jeder geblieben ist.

Das Rollback stellt weder die Datenbank noch die .env noch die freigegebenen Dateien wieder her. Planen Sie die Wiederherstellung nach einer Migration oder geänderter Daten separat. Die aufbewahrten Versionen ersetzen kein Backup.

Läuft ein Deployment und müssen Sie es abbrechen, klicken Sie auf Deployment abbrechen. Warten Sie, bis der Status den Abbruch bestätigt, und prüfen Sie die Website. Die Anfrage kann eintreffen, wenn ein Vorgang bereits läuft; der Abbruch macht dessen Datenänderungen nicht rückgängig und ersetzt kein Rollback nach der Aktivierung.

Der Laravel-Scheduler

Die Aufgaben, die Laravel in routes/console.php plant, laufen nur, wenn etwas jede Minute php artisan schedule:run startet. Beim Verbinden eines Laravel-Projekts ist Den Laravel-Scheduler einplanen angehakt: Wenn das erste Deployment erfolgreich abgeschlossen ist, fügen wir diesen Job Ihrem Cron hinzu, und das Log dieses Deployments bestätigt es.

* * * * * /opt/alt/php84/usr/bin/php /home/tu_usuario/deploy/nombre-repo/current/artisan schedule:run >/dev/null 2>&1 # hostsuar-deploy-12

Er verwendet die PHP-Version, die Ihr Konto beim Einplanen gewählt hat, und die Zahl am Ende kennzeichnet das Repository. Da er über current läuft, nutzt jede Ausführung die zu diesem Zeitpunkt veröffentlichte Version: Sie müssen ihn nicht bei jedem Deployment anpassen. Er ist ein Job wie jeder andere, Sie sehen ihn unter cPanel > Cron-Jobs und können ihn ändern oder löschen. Ändern Sie später die PHP-Version des Kontos, behält der Job seine eigene: Ändern Sie sie auch dort.

Enthält Ihr Cron bereits einen Job mit schedule:run, zum Beispiel aus der vorherigen Installation, fügen wir keinen weiteren hinzu: Mit zweien würde jede geplante Aufgabe doppelt laufen. Das Log des Deployments nennt den gefundenen Job und den Befehl, den Sie eintragen sollten. Stammt er aus der vorherigen Installation, ändern Sie ihn so, dass er auf das current von Deploy+ zeigt. Jobs anderer mit Deploy+ veröffentlichter Anwendungen im selben Konto zählen nicht.

Wenn Sie die Konfiguration des Repositorys entfernen, bleibt der Job bestehen, ebenso wie die veröffentlichte Website.

Queue-Worker und dauerhafte Prozesse

In den Tarifen Avanza, Max und Elastic können ein Queue-Worker, Horizon oder ein eigener Befehl als dauerhafte Prozesse über Tools > Prozesse dauerhaft laufen. Für eine mit Deploy+ veröffentlichte Anwendung ist der Ordner des Prozesses deploy/nombre-repo/current: Bei jedem Start wechselt er in current, das immer auf die aktive Version zeigt.

Ein Worker lädt den Code beim Start und liest ihn danach nicht erneut. Deshalb startet Deploy+ nach jedem abgeschlossenen Deployment die dauerhaften Prozesse neu, die in dieser Anwendung arbeiten, also die, deren Ordner ihr current oder ein Ordner darin ist. Das geschieht auch, wenn Sie im Verlauf zu einer früheren Version zurückkehren. Jeder Worker beendet den laufenden Job und startet innerhalb einer Sekunde mit dem veröffentlichten Code neu.

Das Log des Deployments führt dazu eine Zeile pro Prozess, zum Beispiel „Reiniciado «Worker de pedidos»: en marcha con la versión nueva“ (neu gestartet, läuft mit der neuen Version). Konnte einer nicht neu gestartet werden, steht das in der Zeile, und das Deployment gilt trotzdem als abgeschlossen, weil die Version bereits veröffentlicht ist: Starten Sie ihn über Tools > Prozesse neu.

Hat die Anwendung Prozesse, zeigt ihre Übersicht in Deploy+ sie im Block Prozesse dieser Anwendung mit Status und ausgeführtem Befehl. In einem Laravel-Projekt ohne Worker enthält das Menü des Repositorys (der Pfeil neben Jetzt deployen) Queue-Worker hinzufügen, das die Einrichtung unter Prozesse mit bereits eingetragenem Anwendungsordner und der PHP-Version Ihres Kontos öffnet. Beim Verbinden eines neuen Laravel-Projekts können Sie Einen Queue-Worker am Laufen halten anhaken: Er wird angelegt, wenn das erste Deployment erfolgreich abgeschlossen ist, mit der Warteschlange default, und das Log dieses Deployments bestätigt es oder erklärt, warum er nicht angelegt werden konnte, etwa wenn im Tarif keine Prozesse mehr frei sind.

php artisan queue:restart oder horizon:terminate sind im Skript nicht nötig: Das Skript läuft in der neuen Version, bevor sie aktiviert wird; ein Neustart von dort würde den Worker also mit der vorherigen Version neu starten.

Haben Sie keine dauerhaften Prozesse und arbeiten Sie die Warteschlange über den Scheduler ab, startet jede Ausführung mit dem zu diesem Zeitpunkt veröffentlichten Code, und Sie müssen nichts neu starten.

PHP-Version

Die PHP-Version einer mit Deploy+ veröffentlichten Website wird nicht im Bereich PHP des Kundenbereichs geändert, weil jedes Deployment den veröffentlichten Ordner ersetzt. Legen Sie sie in der .htaccess im Web-Stammverzeichnis Ihres Repositorys fest oder verwenden Sie die Standardversion des Kontos. Das erklären wir in PHP-Version einer mit Deploy+ veröffentlichten Website.

Wie das Deployment-Tool funktioniert

Das System legt in ~/deploy/nombre-repo/ eine Struktur mit drei Hauptverzeichnissen an: releases/ enthält jede deployte Version mit Zeitstempel, current ist ein symbolischer Link auf die aktive Version, und shared/ enthält freigegebene Dateien wie .env und storage/. Ihr Webverzeichnis (public_html oder ein anderes) zeigt auf current, das wiederum auf die aktive Version in releases/ zeigt.

Wenn Sie ein Deployment ausführen, wird ein neuer Ordner in releases/ angelegt, der Code geklont, die Skripte ausgeführt, und sobald alles bereit ist, wird current auf die neue Version umgestellt. Der Wechsel des Links geht schnell, garantiert aber allein nicht, dass alle Anfragen, Prozesse oder Schemaänderungen während der Veröffentlichung kompatibel sind. Das Rollback funktioniert genauso: Es stellt current einfach auf eine frühere, bereits vorhandene Version um.

Geklont wird mit Tiefe 1: Jede Version erhält die Dateien des letzten Commits des Branches, nicht die Historie des Repositorys. Bei einem jahrelang gepflegten Repository wiegt die Historie deutlich mehr als der Code selbst, daher ist das Deployment viel schneller und jede Version belegt weniger Speicherplatz in Ihrem Konto. Braucht Ihr Deployment-Skript die Historie (zum Beispiel git describe oder git rev-list --count, um eine Versionsnummer zu erzeugen), findet es sie nicht. Genügt es Ihnen, den Commit zu identifizieren, verwenden Sie $HOSTSUAR_DEPLOY_COMMIT oder $HOSTSUAR_DEPLOY_COMMIT_SHORT; brauchen Sie eine Versionsnummer, speichern Sie sie aus Ihrem CI-System in einer Datei oder berechnen Sie sie auf andere Weise.

Fehlerbehebung

Das Konto hat keinen SSH-Zugang: Das Tool versucht, ihn automatisch zu aktivieren. Lehnt der Server den Schlüssel auch nach einer Neuinstallation ab, führen Sie das Deployment erneut aus und wenden Sie sich mit dem Log an den Support; das Tool verwendet einen verwalteten Schlüssel und hängt nicht vom cPanel-Passwort ab. Es läuft bereits ein Deployment: Pro Repository kann nur ein Deployment aktiv sein; warten Sie, bis es abgeschlossen ist, oder brechen Sie es ab. Eigene Skripte schlagen fehl: Sehen Sie im Log des Deployments nach, welcher Befehl fehlgeschlagen ist; im Bash-Modus nennt die letzte Zeile den genauen Befehl, bei dem es gestoppt hat. Schlägt ein für Bash geschriebenes Skript im Modus „ein Befehl pro Zeile“ fehl (ein cd oder export, das nicht in die nächste Zeile wirkt, ein if über mehrere Zeilen), wechseln Sie in den Modus Vollständiges Bash-Skript. Ein Fehler vor der Aktivierung verhindert die Veröffentlichung des neuen Codes; prüfen Sie auch mögliche Änderungen an freigegebenen Daten. Webhook wird nicht ausgelöst: Prüfen Sie in den Webhook-Einstellungen des Anbieters (bei GitHub Settings → Webhooks), ob er angelegt ist, und sehen Sie sich die letzten Zustellungen an. Steht in der Übersicht des Repositorys „Webhook ausstehend“, verwenden Sie Installieren; steht dort „Manueller Webhook“, kopieren Sie die URL aus den Details und fügen Sie sie selbst beim Anbieter ein. Der Anbieter lehnt das Token beim Klonen ab: Jeder Anbieter meldet das anders („HTTP Basic: Access denied“ bei GitLab, ein 403 bei GitHub, „Invalid or expired token“ bei Bitbucket). Das Log des Deployments übersetzt diese Meldungen und nennt die fehlende Berechtigung oder ob das Token abgelaufen ist.