Zum Inhalt springen
Vimonto Deploy
Sprache
Loslegen
Menü

Deployments

Deploys, die deine Site nie lahmlegen

Jeder Deploy baut ein frisches Release neben dem Live-Release und schaltet erst um, wenn jeder Schritt erfolgreich war. Pushe auf deinen Branch, rufe aus der CI eine Deploy-URL auf oder klicke auf Jetzt deployen.

Jetzt deployenDoku zu Deployments lesen

So funktioniert's

Vier Schritte, und nur der letzte berührt die Live-Site

  1. 1

    Code abrufen

    Dein Branch wird in ein neues Release-Verzeichnis geklont, das nach Datum und Uhrzeit benannt ist. Commit, Autor und Commit-Nachricht werden festgehalten.

  2. 2

    Release bauen

    Die gemeinsame .env (und bei Laravel storage/) wird verlinkt, dann läuft dein Deploy-Skript im neuen Release als Benutzer der Site.

  3. 3

    Atomar live gehen

    current wird mit einem einzigen Rename auf das neue Release gesetzt. PHP-FPM lädt neu, damit OPcache die neuen Dateien sieht, und die Queue-Worker starten neu.

  4. 4

    Fünf Releases behalten

    Ältere Releases werden aufgeräumt; die fünf neuesten bleiben auf dem Server, sodass ein Rollback sofort und ohne Build klappt.

Deploy-Skript

Ein Deploy-Skript, das du lesen und ändern kannst

Jede Site startet mit einem Deploy-Skript, das zu ihrem Framework passt. Es ist reines Bash, läuft mit set -e im neuen Release, und du bearbeitest es im Browser.

Nutze $VIMONTO_PHP und $VIMONTO_COMPOSER statt php und composer, damit das Skript der PHP-Version der Site folgt, wenn du sie änderst. Auch Branch und Commit des laufenden Deploys stehen dir zur Verfügung.

Deploy-Skript — Laravel-Standard
$VIMONTO_COMPOSER install --no-dev --no-interaction --prefer-dist --optimize-autoloader

if [ -f package.json ]; then
    if [ -f package-lock.json ]; then npm ci; else npm install; fi
    npm run build
fi

$VIMONTO_PHP artisan storage:link --force
$VIMONTO_PHP artisan migrate --force
$VIMONTO_PHP artisan optimize

Starte einen Deploy so, wie es zu dir passt

  • Push to Deploy

    Verknüpfe ein Repository von GitHub, GitLab (auch selbst gehostet) oder Bitbucket, und ein Webhook wird für dich angelegt. Pushes auf den Branch der Site werden deployt, andere Branches ignoriert.

  • Eine Deploy-URL für die CI

    Rufe als letzten Schritt deiner Pipeline eine geheime URL per POST auf, damit ein Deploy erst startet, wenn deine Tests grün sind. Die Antworten sind schlichtes JSON.

  • Jetzt deployen

    Ein Button im Site-Header. Verfolge die Phasen live oder schließe die Seite: Der Deploy läuft auf dem Server, und du bekommst eine Nachricht, sobald er fertig ist.

  • API und CLI

    Starte Deploys aus eigenen Skripten über die REST-API oder aus der CI mit der Deploy-CLI und --watch, damit ein fehlgeschlagener Deploy die Pipeline rot färbt.

    Automatisierung

Verfolge jeden Deploy in Echtzeit

Die Seite eines Deploys zeigt die Phasen Abrufen, Build und Live, den laufenden Schritt und die Ausgabe jedes Schritts. Ein abgeschlossener oder fehlgeschlagener Deploy schickt eine Benachrichtigung, in der App, per E-Mail oder an deinen eigenen Endpunkt.

Ein abgeschlossener Deploy in Vimonto Deploy mit den Phasen Abrufen, Build und Live, den Commit-Details und dem Log jedes Schritts
Ein einzelner Deploy: Phasen, Commit und Log.

Schlägt ein Deploy fehl, ändert sich nichts

Scheitert das Abrufen des Codes oder das Deploy-Skript, wird das neue Release verworfen und current nicht angerührt. Besucher bekommen weiter die Version, die live war, und die Deploy-Seite zeigt den Fehler mit dem vollständigen Log.

Zurück geht es genauso schnell: Wähle bei einem früheren Deploy Zurücksetzen, und dieses Release ist wieder live, ohne dass etwas gebaut wird. Datenbankmigrationen werden nicht zurückgerollt; mach sie selbst rückgängig, wenn ein Release das erfordert.

  • Pro Site läuft immer nur ein Deploy gleichzeitig
  • Der erste Deploy baut die .env auf deiner .env.example auf
  • Jede .env-Änderung bleibt erhalten: Stelle eine der letzten 50 wieder her
  • Lieber schnellere Builds? Stelle eine Site auf In-place-Deploys um

Rollbacks in der Doku

Sicherere Releases

  • Staging-Sites

    Eine Kopie einer Site für einen anderen Branch, etwa develop, unter eigener Adresse und mit eigener Datenbank. Jeder Push auf diesen Branch deployt sie.

  • Sicherheitsprüfungen

    Jedes Deployment prüft die Composer- und npm-Abhängigkeiten des neuen Releases, bevor es live geht. Wähle pro Site, ob eine bekannte Schwachstelle warnt oder das Deployment stoppt.

  • Was schiefging

    Ein fehlgeschlagenes Deployment wird anhand seines Logs in verständlicher Sprache erklärt, mit Lösungsvorschlägen, die wahrscheinlichste zuerst.

Fragen zu Deployments

Muss ich die Deploy-Seite geöffnet lassen?

Nein. Deploys laufen als Hintergrundaufgaben auf dem Server. Schließ die Seite ruhig; wer den Deploy gestartet hat, bekommt eine Nachricht, sobald er fertig ist, und jeder Deploy steht auf der Aktivitätsseite und im Audit-Log.

Wie viele Releases werden aufbewahrt?

Fünf: die neuesten Releases, immer einschließlich des Live-Release. Ältere werden nach jedem erfolgreichen Deploy entfernt.

Von welchen Git-Hosts kann ich deployen?

GitHub, GitLab (auch selbst gehostetes GitLab) und Bitbucket, jeweils mit Push to Deploy. Jeder andere Git-Server funktioniert über eine eigene Git-URL mit dem Deploy Key der Site; solche Deploys startest du über die Deploy-URL.

Kann ich auch ohne Zero Downtime deployen?

Ja. Mit ausgeschalteten Zero-Downtime-Deploys aktualisiert jeder Deploy ein einziges Release an Ort und Stelle. Dabei bleiben vendor/ und node_modules/ erhalten, und der Build ist schneller. Dafür verzichtest du auf Rollbacks, und Besucher sehen die Site eventuell, während sie gebaut wird.

Verwandte Seiten

Dein nächster Deploy ist live, bevor dein Kaffee fertig ist.

Erstelle eine Organisation, verbinde einen Server und pushe. Mehr nicht.

Jetzt deployenDoku lesen