Deployment Live

Vorbereitung des Releases

Wir unterscheiden zwischen Feature Release und Hotfix Release.

Bei einem Feature Release wird der normale Development Prozess durchlaufen und auf dem Dev und Staging getestet.

Die Hotfixes werden dann direkt im release branch commited/gepusht und auf der Release Env getestet.

Feature Release

Nachdem das Release auf dem Staging erfolgreich getestet wurde, muss der staging in den master branch gemerged werden sowie die Version getaggt werden. Dazu gibt es auf dem Dev Server ein entsprechendes Script.

./scripts/deployment/build-release-core.sh

Hier bitte <minor> eins hochzählen.

<major>.<minor>.<bugfixes>

Hotfix Release

Nachdem der Fix auf dem Release erfolgreich getestet wurde, muss der release in den master branch gemerged werden sowie die Version getaggt werden. Dazu gibt es auf dem Dev Server ein entsprechendes Script.

./scripts/deployment/build-hotfix-release-core.sh

Hier <bugfixes> eins hochzählen.

<major>.<minor>.<bugfixes>

Abschließend wird noch geprüft ob Änderungen außerhalb des Repositories erforderlich sind. Dies wird durch ein kurzes Kommentar auf der Console ausgegeben.

Schritte auf dem Live Server

Als erstes müssen wir checken ob es Datenbank Updates etc. gibt. Dazu gibt es im Repository den Folder bin/riddle/releases/updates/current. Darin befinden sich drei Files: current.cron, current.notes sowie current.sql.

Updates außerhalb vom Repository

In current.sql befinden sich die SQL Updates – sofern es welche gibt. Diese müssen dann von Hand über die MySQL Console ausgeführt werden. Die Updates müssen vor dem eigentlichen Deploy ausgeführt werden. Man kann das File zwar auch automatisch vom Deployment Script ausführen lassen aber aufgrund der Historie würde ich das lieber noch eine Zeit lang selbst machen.

Sofern im current.cron file Commands stehen müssen diese über das default Command crontab -e in die Crontab eingetragen werden. Die Crons müssen nach dem eigentlichen Deploy eingetragen werden.

In current.notes stehen dann allgemeine Infos drin – je nach dem.

Deploy commands

Wir unterscheiden zwei Deployments: einmal alles komplett (Backend und Frontend) und einmal nur das Frontend.

Backend und Frontend

Das folgende Script macht ein git pull im master branch und leert die Caches (Symfony, Riddle und OPcache).

./scripts/deployment/deploy-core.sh

Während die Caches geleert und aufgewärmt werden ist der Maintenance Mode aktiv. Das Leeren / Aufwärmen dauert in der Regel 1-3 Sekunden.

Frontend only

Das folgende Script macht nur ein git pull im master branch. Dadurch dass nur JS und CSS files aktualisiert wurden, ist kein Cache Clear im Backend erforderlich. Dadurch haben wir auch keine Downtime.

./scripts/deployment/deploy-core-frontend.sh

Probleme nach einem Deploy

Es kann vorkommen, dass mal was hängt. In der Regel kann man dies durch erneutes Leeren der Caches beheben.

Symfony und Riddle Cache

Das Command leert den Symfony Cache, den OPcache und ein paar eigene Settings (im Memcached).

php72 bin/console riddle:cache-clear --env=prod --subdomain=www --symfony=1

Wenn Fehler beim Leeren des Symfony Caches auftreten hilft auch oft ein manuelles Löschen des Cache Folders.

rm -rf var/log/cache/*

Mit diesem Command sollten wir aber vorsichtig umgehen, da die Masse an Requests das System im ungecachten Zustand lahm legen kann.

OPcache

Der OPcache speichert PHP classes. Beispielsweise sind hier alte Entity Classes gecacht (neue Getter und Setter funktionieren ohne Leeren des OPcaches nicht).

./scripts/deployment/opcache-reset-by-vhost.sh live

Manchmal auch zwischendurch ganz hilfreich wenn Probleme auftreten.

Maintenance mode

Die folgenden Commands togglen den Maintenance mode.

php72 bin/console riddle:maintenance-mode on

php72 bin/console riddle:maintenance-mode off

Verbesserungen

• Rollback
• Update-Paket (Build) anstatt git pull