Ein selbst entwickeltes WordPress-Theme ist Software.<\/p>\n\n\n\n
Es enth\u00e4lt PHP, JavaScript, CSS, Templates, Assets und Konfiguration. \u00c4nderungen an einer Datei k\u00f6nnen Auswirkungen auf andere Teile des Systems haben. Fehler k\u00f6nnen die komplette Website unbrauchbar machen.<\/p>\n\n\n\n
Trotzdem werden WordPress-Themes erstaunlich oft anders behandelt als andere Software:<\/p>\n\n\n\n
Theme \u00e4ndern\n \u2193\nZIP erstellen\n \u2193\nWordPress \u00f6ffnen\n \u2193\nTheme hochladen\n \u2193\nhoffen<\/code><\/pre>\n\n\n\nOder noch direkter:<\/p>\n\n\n\n
FTP\n \u2193\nDatei \u00fcberschreiben\n \u2193\nfertig<\/code><\/pre>\n\n\n\nF\u00fcr kleine \u00c4nderungen funktioniert das erstaunlich lange.<\/p>\n\n\n\n
Bis es nicht mehr funktioniert.<\/p>\n\n\n\n
Dann entstehen unangenehme Fragen:<\/p>\n\n\n\n
\n- Welcher Stand l\u00e4uft gerade auf dem Server?<\/li>\n\n\n\n
- Entspricht dieser Stand \u00fcberhaupt noch dem lokalen Projekt?<\/li>\n\n\n\n
- Welche Dateien wurden beim letzten Update ver\u00e4ndert?<\/li>\n\n\n\n
- Liegen alte Dateien auf dem Server, die lokal l\u00e4ngst gel\u00f6scht wurden?<\/li>\n\n\n\n
- Welcher Commit entspricht der Produktion?<\/li>\n\n\n\n
- Kann der vorherige Zustand wiederhergestellt werden?<\/li>\n\n\n\n
- Wurde das Theme vor dem Deployment \u00fcberhaupt gepr\u00fcft?<\/li>\n\n\n\n
- Funktioniert die Website nach dem Deployment tats\u00e4chlich?<\/li>\n<\/ul>\n\n\n\n
Die L\u00f6sung ist nicht ein besserer FTP-Client.<\/p>\n\n\n\n
Die L\u00f6sung besteht darin, das Theme wie das zu behandeln, was es ist:<\/p>\n\n\n\n
ein deploybares Software-Artefakt.<\/strong><\/p>\n\n\n\n
\n\n\n\nDas eigentliche Problem: Wo liegt die Wahrheit?<\/h2>\n\n\n\n
Bei einem manuell gepflegten WordPress-Theme entstehen schnell mehrere Zust\u00e4nde:<\/p>\n\n\n\n
Lokaler Rechner\n \u2502\n \u251c\u2500\u2500 Version A\n \u2502\nGitHub\n \u251c\u2500\u2500 Version B\n \u2502\nWebserver\n \u2514\u2500\u2500 Version C<\/code><\/pre>\n\n\n\nSolange alle drei ungef\u00e4hr gleich sind, f\u00e4llt das kaum auf.<\/p>\n\n\n\n
Nach einigen manuellen \u00c4nderungen sieht die Realit\u00e4t m\u00f6glicherweise so aus:<\/p>\n\n\n\n
Git Repository\n\u251c\u2500\u2500 functions.php\n\u251c\u2500\u2500 style.css\n\u251c\u2500\u2500 assets\/\n\u2502 \u251c\u2500\u2500 site.css\n\u2502 \u2514\u2500\u2500 browser.js\n\u2514\u2500\u2500 templates\/\n\n\nProduktionsserver\n\u251c\u2500\u2500 functions.php\n\u251c\u2500\u2500 style.css\n\u251c\u2500\u2500 assets\/\n\u2502 \u251c\u2500\u2500 site.css\n\u2502 \u251c\u2500\u2500 browser.js\n\u2502 \u251c\u2500\u2500 category-sort.js\n\u2502 \u2514\u2500\u2500 old-navigation.js\n\u2514\u2500\u2500 templates\/<\/code><\/pre>\n\n\n\nDie letzten beiden JavaScript-Dateien wurden im Repository l\u00e4ngst entfernt.<\/p>\n\n\n\n
Auf dem Server existieren sie aber weiterhin.<\/p>\n\n\n\n
Ein klassischer Datei-Upload kennt keinen gew\u00fcnschten Gesamtzustand. Er kopiert Dateien.<\/p>\n\n\n\n
Ein Deployment sollte etwas anderes tun:<\/p>\n\n\n\n
\nDer Zustand im Repository definiert den Zustand des deployten Themes.<\/p>\n<\/blockquote>\n\n\n\n
Damit wird Git zum Source of Truth<\/strong>.<\/p>\n\n\n\nGit Repository\n \u2502\n \u2502 Source of Truth\n \u25bc\nValidation\n \u2502\n \u25bc\nDeployment\n \u2502\n \u25bc\nWordPress Production<\/code><\/pre>\n\n\n\nProduktion wird aus Git hergestellt.<\/p>\n\n\n\n
Nicht umgekehrt.<\/p>\n\n\n\n
\n\n\n\nVon Datei\u00fcbertragung zu CI\/CD<\/h1>\n\n\n\n
An dieser Stelle lohnt sich die Trennung zweier Begriffe, die h\u00e4ufig zusammengeworfen werden:<\/p>\n\n\n\n
\n- Continuous Integration<\/li>\n\n\n\n
- Continuous Delivery beziehungsweise Continuous Deployment<\/li>\n<\/ul>\n\n\n\n
F\u00fcr ein WordPress-Theme l\u00e4sst sich die Trennung sehr konkret zeigen.<\/p>\n\n\n\n
Continuous Integration<\/h2>\n\n\n\n
CI beantwortet die Frage:<\/p>\n\n\n\n
\nIst dieser Stand grunds\u00e4tzlich deploybar?<\/p>\n<\/blockquote>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
Commit\n \u2502\n \u25bc\nPHP Syntax Check\n \u2502\n \u25bc\nJavaScript Syntax Check\n \u2502\n \u25bc\nTheme Structure Check\n \u2502\n \u25bc\nweitere Tests<\/code><\/pre>\n\n\n\nErst wenn diese Pr\u00fcfungen erfolgreich sind, darf der n\u00e4chste Schritt beginnen.<\/p>\n\n\n\n
Continuous Deployment<\/h2>\n\n\n\n
CD beantwortet anschlie\u00dfend:<\/p>\n\n\n\n
\nWie kommt der gepr\u00fcfte Stand kontrolliert auf das Produktionssystem?<\/p>\n<\/blockquote>\n\n\n\n
Validierter Commit\n \u2502\n \u25bc\nSSH-Verbindung\n \u2502\n \u25bc\nBackup\n \u2502\n \u25bc\nDeployment\n \u2502\n \u25bc\nSmoke Tests<\/code><\/pre>\n\n\n\nGitHub Actions kann beide Aufgaben \u00fcbernehmen.<\/p>\n\n\n\n
\n\n\n\nDie einfachste m\u00f6gliche GitHub Action<\/h1>\n\n\n\n
Eine sehr kleine Deployment-Pipeline k\u00f6nnte so aussehen:<\/p>\n\n\n\n
name: Deploy WordPress Theme\n\non:\n push:\n branches:\n - main\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout\n uses: actions\/checkout@v4\n\n - name: Deploy\n run: |\n rsync -az --delete \\\n .\/ \\\n user@server:\/path\/to\/wp-content\/themes\/my-theme\/<\/code><\/pre>\n\n\n\nDas Prinzip ist bereits sichtbar:<\/p>\n\n\n\n
Push auf main\n \u2193\nGitHub Actions\n \u2193\nRepository auschecken\n \u2193\nrsync\n \u2193\nProduktionsserver<\/code><\/pre>\n\n\n\nAber produktionsreif ist das noch nicht.<\/p>\n\n\n\n
Vor allem fehlen:<\/p>\n\n\n\n
\n- Validierung<\/li>\n\n\n\n
- sichere Credentials<\/li>\n\n\n\n
- Schutz des Deployment-Ziels<\/li>\n\n\n\n
- Vorschau der \u00c4nderungen<\/li>\n\n\n\n
- Backup<\/li>\n\n\n\n
- Verifikation nach dem Deployment<\/li>\n\n\n\n
- brauchbares Feedback<\/li>\n<\/ul>\n\n\n\n
Diese Punkte machen aus einem automatisierten Datei-Upload eine Deployment-Pipeline.<\/p>\n\n\n\n
\n\n\n\nSSH statt Zugangsdaten im Workflow<\/h1>\n\n\n\n
GitHub Actions muss sich am Webserver authentifizieren k\u00f6nnen.<\/p>\n\n\n\n
Daf\u00fcr eignet sich ein separater SSH-Key.<\/p>\n\n\n\n
Ein Ed25519-Key kann beispielsweise erzeugt werden mit:<\/p>\n\n\n\n
ssh-keygen \\\n -t ed25519 \\\n -C \"github-actions-wordpress\" \\\n -f github-actions-wordpress<\/code><\/pre>\n\n\n\nEs entstehen zwei Dateien:<\/p>\n\n\n\n
github-actions-wordpress\ngithub-actions-wordpress.pub<\/code><\/pre>\n\n\n\nDie .pub<\/code>-Datei enth\u00e4lt den \u00f6ffentlichen Schl\u00fcssel.<\/p>\n\n\n\nDieser wird auf dem Server autorisiert.<\/p>\n\n\n\n
Der private Schl\u00fcssel geh\u00f6rt dagegen weder in das Theme noch in das Repository.<\/p>\n\n\n\n
\n\n\n\nGitHub Secrets<\/h1>\n\n\n\n
GitHub Actions stellt daf\u00fcr Repository Secrets bereit.<\/p>\n\n\n\n
F\u00fcr ein einfaches WordPress-Deployment k\u00f6nnen beispielsweise folgende Werte ben\u00f6tigt werden:<\/p>\n\n\n\n
SSH_HOST\nSSH_USER\nSSH_PRIVATE_KEY\nTHEME_PATH<\/code><\/pre>\n\n\n\nDer Zielpfad k\u00f6nnte konzeptionell so aussehen:<\/p>\n\n\n\n
\/home\/user\/public_html\/wp-content\/themes\/my-theme<\/code><\/pre>\n\n\n\nDer Workflow kann anschlie\u00dfend darauf zugreifen:<\/p>\n\n\n\n
${{ secrets.SSH_HOST }}\n${{ secrets.SSH_USER }}\n${{ secrets.SSH_PRIVATE_KEY }}\n${{ secrets.THEME_PATH }}<\/code><\/pre>\n\n\n\nDer private Schl\u00fcssel taucht damit nicht im Repository auf.<\/p>\n\n\n\n
Das ist ein grundlegendes Prinzip von Deployment-Konfiguration:<\/p>\n\n\n\n
\nCode geh\u00f6rt ins Repository. Secrets nicht.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nSSH vorbereiten<\/h1>\n\n\n\n
Der Runner von GitHub Actions existiert nur f\u00fcr die Dauer des Jobs.<\/p>\n\n\n\n
Die SSH-Konfiguration muss deshalb w\u00e4hrend des Workflows erstellt werden.<\/p>\n\n\n\n
Beispielsweise:<\/p>\n\n\n\n
- name: Configure SSH\n shell: bash\n run: |\n mkdir -p ~\/.ssh\n chmod 700 ~\/.ssh\n\n printf '%s\\n' \\\n \"${{ secrets.SSH_PRIVATE_KEY }}\" \\\n > ~\/.ssh\/id_ed25519\n\n chmod 600 ~\/.ssh\/id_ed25519\n\n ssh-keyscan \\\n -H \"${{ secrets.SSH_HOST }}\" \\\n >> ~\/.ssh\/known_hosts<\/code><\/pre>\n\n\n\nDanach kann der Workflow den Server erreichen.<\/p>\n\n\n\n
Ein separater Verbindungstest ist sinnvoll:<\/p>\n\n\n\n
- name: Test SSH connection\n run: |\n ssh user@server \"\n echo 'SSH connection established'\n hostname\n whoami\n \"<\/code><\/pre>\n\n\n\nDas wirkt zun\u00e4chst redundant.<\/p>\n\n\n\n
F\u00fcr die Fehlersuche ist die Trennung aber wertvoll.<\/p>\n\n\n\n
Scheitert sp\u00e4ter rsync<\/code>, ist bereits bekannt, ob grunds\u00e4tzlich ein SSH-Problem vorliegt oder tats\u00e4chlich das Deployment fehlschl\u00e4gt.<\/p>\n\n\n\n
\n\n\n\nVor dem Deployment muss das Theme gepr\u00fcft werden<\/h1>\n\n\n\n
Automatisierung sollte Fehler nicht nur schneller ausliefern.<\/p>\n\n\n\n
Sie sollte bekannte Fehlerklassen verhindern.<\/p>\n\n\n\n
Bei einem klassischen WordPress-Theme k\u00f6nnen bereits sehr einfache Pr\u00fcfungen viel abfangen.<\/p>\n\n\n\n
PHP-Syntax pr\u00fcfen<\/h2>\n\n\n\n
PHP besitzt daf\u00fcr bereits einen eingebauten Syntaxcheck:<\/p>\n\n\n\n
php -l functions.php<\/code><\/pre>\n\n\n\nF\u00fcr alle PHP-Dateien:<\/p>\n\n\n\n
find . \\\n -type f \\\n -name \"*.php\" \\\n -print0 \\\n | xargs -0 -n1 php -l<\/code><\/pre>\n\n\n\nEin Syntaxfehler f\u00fchrt zum Abbruch der Pipeline.<\/p>\n\n\n\n
Damit kann beispielsweise ein versehentlich fehlendes Semikolon nicht mehr einfach auf Produktion landen.<\/p>\n\n\n\n
\n\n\n\nJavaScript pr\u00fcfen<\/h1>\n\n\n\n
Node kann JavaScript-Dateien zumindest syntaktisch pr\u00fcfen:<\/p>\n\n\n\n
node --check assets\/js\/browser.js<\/code><\/pre>\n\n\n\nAutomatisiert:<\/p>\n\n\n\n
for file in $(find assets -type f -name \"*.js\"); do\n node --check \"$file\"\ndone<\/code><\/pre>\n\n\n\nDas ersetzt keine Tests und keinen Linter.<\/p>\n\n\n\n
Es verhindert aber bereits triviale Syntaxfehler.<\/p>\n\n\n\n
\n\n\n\nWordPress-Struktur pr\u00fcfen<\/h1>\n\n\n\n
Auch die erwartete Theme-Struktur l\u00e4sst sich kontrollieren.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
REQUIRED_FILES=(\n \"style.css\"\n \"functions.php\"\n \"index.php\"\n \"header.php\"\n \"footer.php\"\n \"404.php\"\n)\n\nfor FILE in \"${REQUIRED_FILES[@]}\"; do\n if [ ! -f \"$FILE\" ]; then\n echo \"Missing: $FILE\"\n exit 1\n fi\ndone<\/code><\/pre>\n\n\n\nDamit l\u00e4sst sich eine weitere Klasse unangenehmer Fehler verhindern:<\/p>\n\n\n\n
\nEine zentrale Datei wurde beim Refactoring versehentlich gel\u00f6scht oder nicht committed.<\/p>\n<\/blockquote>\n\n\n\n
Man kann noch weitergehen und beispielsweise leere PHP-Templates erkennen:<\/p>\n\n\n\n
if [ ! -s \"$FILE\" ]; then\n echo \"Template is empty: $FILE\"\n exit 1\nfi<\/code><\/pre>\n\n\n\nDas ist simpel.<\/p>\n\n\n\n
Aber genau solche simplen Guardrails sind wertvoll.<\/p>\n\n\n\n
\n\n\n\nPoka-Yoke in der Deployment-Pipeline<\/h1>\n\n\n\n
Das Prinzip dahinter ist dasselbe wie bei Poka-Yoke in Softwarearchitektur und Entwicklungsprozessen:<\/p>\n\n\n\n
\nEinen vermeidbaren Fehler nicht dokumentieren, sondern technisch erschweren oder unm\u00f6glich machen.<\/p>\n<\/blockquote>\n\n\n\n
Eine README k\u00f6nnte sagen:<\/p>\n\n\n\n
\nVor dem Deployment bitte kontrollieren, ob index.php<\/code> vorhanden ist.<\/p>\n<\/blockquote>\n\n\n\nEine Pipeline kann stattdessen sagen:<\/p>\n\n\n\n
index.php fehlt\n \u2193\nPipeline rot\n \u2193\nkein Deployment<\/code><\/pre>\n\n\n\nDie zweite Variante ist zuverl\u00e4ssiger.<\/p>\n\n\n\n
\n\n\n\nWarum rsync<\/code>?<\/h1>\n\n\n\nF\u00fcr ein klassisches WordPress-Theme ist rsync<\/code> ein sehr passendes Werkzeug.<\/p>\n\n\n\nEs synchronisiert Verzeichnisse effizient und \u00fcbertr\u00e4gt nur notwendige \u00c4nderungen.<\/p>\n\n\n\n
Ein typischer Aufruf:<\/p>\n\n\n\n
rsync -az \\\n .\/ \\\n user@server:\/path\/to\/theme\/<\/code><\/pre>\n\n\n\nInteressant wird insbesondere die Option:<\/p>\n\n\n\n
--delete<\/code><\/pre>\n\n\n\nDamit werden Dateien auf dem Ziel entfernt, die im Quellverzeichnis nicht mehr existieren.<\/p>\n\n\n\n
\n\n\n\nWarum --delete<\/code> wichtig ist<\/h1>\n\n\n\nNehmen wir an, ein Theme enthielt fr\u00fcher:<\/p>\n\n\n\n
assets\/js\/\n\u251c\u2500\u2500 browser.js\n\u251c\u2500\u2500 category-sort.js\n\u2514\u2500\u2500 old-navigation.js<\/code><\/pre>\n\n\n\nNach einem Refactoring existiert im Repository nur noch:<\/p>\n\n\n\n
assets\/js\/\n\u2514\u2500\u2500 browser.js<\/code><\/pre>\n\n\n\nEin normaler Upload \u00fcberschreibt m\u00f6glicherweise browser.js<\/code>.<\/p>\n\n\n\nDie anderen Dateien bleiben aber auf dem Server.<\/p>\n\n\n\n
Mit:<\/p>\n\n\n\n
rsync --delete<\/code><\/pre>\n\n\n\nwird das Ziel tats\u00e4chlich synchronisiert.<\/p>\n\n\n\n
Danach gilt:<\/p>\n\n\n\n
Repository\n =\nProduktionsverzeichnis<\/code><\/pre>\n\n\n\nDas ist genau das gew\u00fcnschte Verhalten.<\/p>\n\n\n\n
\n\n\n\nWarum --delete<\/code> gleichzeitig gef\u00e4hrlich ist<\/h1>\n\n\n\nAngenommen, der konfigurierte Zielpfad lautet versehentlich:<\/p>\n\n\n\n
\/wp-content\/<\/code><\/pre>\n\n\n\nstatt:<\/p>\n\n\n\n
\/wp-content\/themes\/my-theme\/<\/code><\/pre>\n\n\n\nDann bekommt der Begriff --delete<\/code> pl\u00f6tzlich eine v\u00f6llig andere Bedeutung.<\/p>\n\n\n\nDeshalb sollte eine produktive Pipeline das Deployment-Ziel \u00fcberpr\u00fcfen.<\/p>\n\n\n\n
Beispielsweise:<\/p>\n\n\n\n
TARGET=\"${THEME_PATH}\"\nEXPECTED_SUFFIX=\"\/wp-content\/themes\/my-theme\"\n\nif [[ \"$TARGET\" != *\"$EXPECTED_SUFFIX\" ]]; then\n echo \"Unsafe deployment target\"\n exit 1\nfi<\/code><\/pre>\n\n\n\nErst danach darf rsync --delete<\/code> ausgef\u00fchrt werden.<\/p>\n\n\n\nDas ist wieder Poka-Yoke:<\/p>\n\n\n\n
Konfigurationsfehler\n \u2193\nGuard erkennt falschen Pfad\n \u2193\nDeployment wird gestoppt<\/code><\/pre>\n\n\n\nstatt:<\/p>\n\n\n\n
Konfigurationsfehler\n \u2193\nrsync --delete\n \u2193\nProblem<\/code><\/pre>\n\n\n\n
\n\n\n\nErst ansehen, dann ver\u00e4ndern: rsync --dry-run<\/code><\/h1>\n\n\n\nEin weiterer sinnvoller Guardrail ist ein Dry Run.<\/p>\n\n\n\n
rsync<\/code> kann berechnen, was passieren w\u00fcrde, ohne tats\u00e4chlich etwas zu ver\u00e4ndern:<\/p>\n\n\n\nrsync -azn \\\n --delete \\\n --itemize-changes \\\n .\/ \\\n user@server:\/path\/to\/theme\/<\/code><\/pre>\n\n\n\nDas n<\/code> steht f\u00fcr Dry Run.<\/p>\n\n\n\nMit:<\/p>\n\n\n\n
--itemize-changes<\/code><\/pre>\n\n\n\nwird zus\u00e4tzlich sichtbar, welche \u00c4nderungen geplant sind.<\/p>\n\n\n\n
Beispielsweise:<\/p>\n\n\n\n
>f.st...... assets\/css\/site.css\n>f.st...... functions.php\n>f+++++++++ inc\/helpers.php\n*deleting assets\/js\/category-sort.js<\/code><\/pre>\n\n\n\nDamit besitzt die Pipeline vor dem eigentlichen Deployment bereits eine Art \u00c4nderungsplan.<\/p>\n\n\n\n
Das ist insbesondere nach gr\u00f6\u00dferen Refactorings hilfreich.<\/p>\n\n\n\n
\n\n\n\nBackup vor Deployment<\/h1>\n\n\n\n
Validierung reduziert das Risiko.<\/p>\n\n\n\n
Sie beseitigt es nicht.<\/p>\n\n\n\n
Deshalb sollte unmittelbar vor dem Deployment der aktuelle Produktionsstand gesichert werden.<\/p>\n\n\n\n
Ein Backupname kann beispielsweise enthalten:<\/p>\n\n\n\n
my-theme-20260913-112500-a91e42f<\/code><\/pre>\n\n\n\nDarin stecken:<\/p>\n\n\n\n
Theme\nTimestamp\nCommit<\/code><\/pre>\n\n\n\nKonzeptionell:<\/p>\n\n\n\n
Aktuelles Production Theme\n \u2502\n \u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba Backup\n \u2502\n \u25bc\n neues Deployment<\/code><\/pre>\n\n\n\nEin einfacher serverseitiger Backup-Schritt k\u00f6nnte so aussehen:<\/p>\n\n\n\n
TIMESTAMP=$(date -u +\"%Y%m%d-%H%M%S\")\n\ncp -a \\\n \/path\/to\/theme \\\n \/path\/to\/backups\/theme-${TIMESTAMP}<\/code><\/pre>\n\n\n\nDamit h\u00e4ngt die Wiederherstellung nicht davon ab, ob irgendwo noch eine passende ZIP-Datei existiert.<\/p>\n\n\n\n
\n\n\n\nBackups brauchen eine Retention Policy<\/h1>\n\n\n\n
Automatische Backups erzeugen ein neues Problem:<\/p>\n\n\n\n
Sie funktionieren.<\/p>\n\n\n\n
Bei jedem Deployment entsteht ein weiteres Verzeichnis.<\/p>\n\n\n\n
Nach gen\u00fcgend Deployments sieht der Server so aus:<\/p>\n\n\n\n
backups\/\n\u251c\u2500\u2500 theme-001\n\u251c\u2500\u2500 theme-002\n\u251c\u2500\u2500 theme-003\n\u251c\u2500\u2500 ...\n\u251c\u2500\u2500 theme-184\n\u2514\u2500\u2500 theme-185<\/code><\/pre>\n\n\n\nDeshalb geh\u00f6rt zur Backup-Strategie auch eine Retention Policy.<\/p>\n\n\n\n
Beispielsweise:<\/p>\n\n\n\n
\nDie letzten zehn Deployments werden behalten.<\/p>\n<\/blockquote>\n\n\n\n
\u00c4ltere Backups werden automatisch entfernt.<\/p>\n\n\n\n
Das Prinzip ist allgemeiner als WordPress:<\/p>\n\n\n\n
\nEin Backup-Konzept definiert nicht nur, wie Sicherungen entstehen, sondern auch, wie lange sie existieren.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nDas eigentliche Deployment<\/h1>\n\n\n\n
Nach Validierung, Zielpr\u00fcfung, Dry Run und Backup kann synchronisiert werden:<\/p>\n\n\n\n
rsync -az \\\n --delete \\\n --itemize-changes \\\n --stats \\\n --human-readable \\\n --exclude=\".git\/\" \\\n --exclude=\".github\/\" \\\n --exclude=\".gitignore\" \\\n --exclude=\"README.md\" \\\n .\/ \\\n user@server:\/path\/to\/theme\/<\/code><\/pre>\n\n\n\nMehrere Optionen verbessern dabei nicht das Deployment selbst, sondern dessen Beobachtbarkeit.<\/p>\n\n\n\n
--itemize-changes<\/code> zeigt die einzelnen \u00c4nderungen.<\/p>\n\n\n\n--stats<\/code> liefert Statistiken.<\/p>\n\n\n\n--human-readable<\/code> macht Gr\u00f6\u00dfen verst\u00e4ndlicher.<\/p>\n\n\n\nDadurch ist im GitHub-Actions-Log nicht nur sichtbar:<\/p>\n\n\n\n
Process exited with code 0<\/code><\/pre>\n\n\n\nsondern auch, was tats\u00e4chlich ver\u00e4ndert wurde.<\/p>\n\n\n\n
\n\n\n\nEin gr\u00fcnes rsync<\/code> bedeutet nicht, dass die Website funktioniert<\/h1>\n\n\n\nDas ist einer der wichtigsten Punkte der gesamten Pipeline.<\/p>\n\n\n\n
Angenommen:<\/p>\n\n\n\n
rsync\n \u2193\nExit Code 0<\/code><\/pre>\n\n\n\nDann wissen wir:<\/p>\n\n\n\n
\nDie Dateien wurden erfolgreich synchronisiert.<\/p>\n<\/blockquote>\n\n\n\n
Wir wissen nicht:<\/p>\n\n\n\n
\nWordPress funktioniert.<\/p>\n<\/blockquote>\n\n\n\n
Ein PHP-Fehler k\u00f6nnte erst beim Ausf\u00fchren eines bestimmten Templates auftreten.<\/p>\n\n\n\n
Eine Funktion k\u00f6nnte zwar syntaktisch korrekt sein, aber zur Laufzeit scheitern.<\/p>\n\n\n\n
Ein Template k\u00f6nnte falsche Daten erwarten.<\/p>\n\n\n\n
Eine Seite k\u00f6nnte nach dem Deployment leer sein.<\/p>\n\n\n\n
Deshalb endet das Deployment nicht mit rsync<\/code>.<\/p>\n\n\n\n
\n\n\n\nSmoke Tests gegen Produktion<\/h1>\n\n\n\n
Nach dem Deployment kann GitHub Actions die echte Website aufrufen.<\/p>\n\n\n\n
Zum Beispiel:<\/p>\n\n\n\n
curl \\\n --silent \\\n --show-error \\\n --location \\\n --output \/tmp\/homepage.html \\\n --write-out \"%{http_code}\" \\\n \"https:\/\/example.com\/\"<\/code><\/pre>\n\n\n\nDann wird der HTTP-Status gepr\u00fcft:<\/p>\n\n\n\n
if [ \"$HTTP_CODE\" != \"200\" ]; then\n exit 1\nfi<\/code><\/pre>\n\n\n\nDasselbe kann f\u00fcr zentrale Seiten geschehen:<\/p>\n\n\n\n
Homepage\nArticles\nwichtige Landingpage<\/code><\/pre>\n\n\n\nDamit pr\u00fcft die Pipeline erstmals nicht mehr nur Dateien.<\/p>\n\n\n\n
Sie pr\u00fcft das laufende System.<\/p>\n\n\n\n
\n\n\n\nHTTP 200 reicht ebenfalls nicht<\/h1>\n\n\n\n
Auch das ist nur eine erste N\u00e4herung.<\/p>\n\n\n\n
Eine Website kann HTTP 200 zur\u00fcckgeben und trotzdem kaputt sein.<\/p>\n\n\n\n
Beispielsweise k\u00f6nnte die Antwort enthalten:<\/p>\n\n\n\n
Fatal error<\/code><\/pre>\n\n\n\noder:<\/p>\n\n\n\n
There has been a critical error on this website.<\/code><\/pre>\n\n\n\nDeshalb kann ein einfacher Smoke Test zus\u00e4tzlich nach bekannten Fehlermustern suchen:<\/p>\n\n\n\n
grep -Eqi \\\n 'Fatal error|Parse error|Uncaught Error|critical error'<\/code><\/pre>\n\n\n\nWerden solche Muster gefunden, schl\u00e4gt die Pipeline fehl.<\/p>\n\n\n\n
Zus\u00e4tzlich kann erwartetes Markup kontrolliert werden:<\/p>\n\n\n\n
grep -qi \"<html\" \/tmp\/homepage.html\ngrep -qi \"<body\" \/tmp\/homepage.html<\/code><\/pre>\n\n\n\nAuch das beweist nicht, dass die Website vollst\u00e4ndig korrekt funktioniert.<\/p>\n\n\n\n
Das ist nicht der Anspruch eines Smoke Tests.<\/p>\n\n\n\n
Der Smoke Test beantwortet eine kleinere Frage:<\/p>\n\n\n\n
\nIst das System nach dem Deployment grunds\u00e4tzlich noch am Leben?<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nValidierung, Tests und Monitoring sind nicht dasselbe<\/h1>\n\n\n\n
Die Pipeline enth\u00e4lt inzwischen mehrere Schutzebenen:<\/p>\n\n\n\n
Static Validation\n \u2502\n \u2502 PHP syntaktisch korrekt?\n \u2502 JS syntaktisch korrekt?\n \u2502 Theme vollst\u00e4ndig?\n \u25bc\nDeployment Guards\n \u2502\n \u2502 Zielpfad korrekt?\n \u2502 \u00c4nderungen plausibel?\n \u25bc\nBackup\n \u2502\n \u25bc\nDeployment\n \u2502\n \u25bc\nSmoke Tests\n \u2502\n \u2502 Server erreichbar?\n \u2502 HTTP 200?\n \u2502 HTML vorhanden?\n \u2502 Fatal Error?\n \u25bc\nProduction<\/code><\/pre>\n\n\n\nJede Ebene beantwortet andere Fragen.<\/p>\n\n\n\n
Keine davon macht die anderen \u00fcberfl\u00fcssig.<\/p>\n\n\n\n
\n\n\n\nDeployment-Feedback ist Teil des Systems<\/h1>\n\n\n\n
Ein Deployment-Workflow sollte nicht nur funktionieren.<\/p>\n\n\n\n
Er sollte verst\u00e4ndlich erkl\u00e4ren, was passiert ist.<\/p>\n\n\n\n
Eine minimale Action zeigt vielleicht:<\/p>\n\n\n\n
Validate \u2713\nDeploy \u2713<\/code><\/pre>\n\n\n\nDas ist besser als nichts.<\/p>\n\n\n\n
Es fehlen aber wichtige Informationen.<\/p>\n\n\n\n
Eine aussagekr\u00e4ftigere Zusammenfassung k\u00f6nnte so aussehen:<\/p>\n\n\n\n
Production deployment succeeded\n\nTheme my-theme\nPrevious version 1.3.1\nDeployed version 1.4.0\nCommit 41ef712\nPlanned changes 17\nPlanned deletions 4\nBackup Created\nBackups remaining 10\nHomepage HTTP 200\nArticles HTTP 200\nFatal-error scan Passed<\/code><\/pre>\n\n\n\nGitHub Actions stellt daf\u00fcr GITHUB_STEP_SUMMARY<\/code> bereit.<\/p>\n\n\n\nBeispielsweise:<\/p>\n\n\n\n
{\n echo \"## Production deployment succeeded\"\n echo \"\"\n echo \"| Item | Result |\"\n echo \"|---|---|\"\n echo \"| Homepage | HTTP 200 |\"\n echo \"| Backup | Created |\"\n echo \"| Fatal-error scan | Passed |\"\n} >> \"$GITHUB_STEP_SUMMARY\"<\/code><\/pre>\n\n\n\nDamit wird die Pipeline selbst zu einem kleinen Deployment-Protokoll.<\/p>\n\n\n\n
\n\n\n\nDie Theme-Version mitf\u00fchren<\/h1>\n\n\n\n
WordPress-Themes besitzen in style.css<\/code> bereits Metadaten:<\/p>\n\n\n\n\/*\nTheme Name: My Theme\nVersion: 1.4.0\n*\/<\/code><\/pre>\n\n\n\nDie Pipeline kann diese Version auslesen:<\/p>\n\n\n\n
VERSION=$(sed -n \\\n 's\/^[[:space:]]*Version:[[:space:]]*\/\/p' \\\n style.css \\\n | head -1)<\/code><\/pre>\n\n\n\nVor dem Deployment l\u00e4sst sich die produktive Version auslesen.<\/p>\n\n\n\n
Danach die neue.<\/p>\n\n\n\n
Das Ergebnis:<\/p>\n\n\n\n
Previous version: 1.3.1\nDeployed version: 1.4.0<\/code><\/pre>\n\n\n\nDamit wird die Theme-Version Teil des Deployment-Prozesses statt nur eine dekorative Angabe in WordPress.<\/p>\n\n\n\n
\n\n\n\nWas geh\u00f6rt nicht auf den Server?<\/h1>\n\n\n\n
Das Repository enth\u00e4lt m\u00f6glicherweise Dateien, die zur Entwicklung geh\u00f6ren, aber nicht zum Theme.<\/p>\n\n\n\n
Beispielsweise:<\/p>\n\n\n\n
.git\/\n.github\/\n.gitignore\nREADME.md\n*.zip\n*.tmp\n*.bak<\/code><\/pre>\n\n\n\nDiese k\u00f6nnen beim Deployment ausgeschlossen werden:<\/p>\n\n\n\n
--exclude=\".git\/\"\n--exclude=\".github\/\"\n--exclude=\".gitignore\"\n--exclude=\"README.md\"\n--exclude=\"*.zip\"\n--exclude=\"*.tmp\"\n--exclude=\"*.bak\"<\/code><\/pre>\n\n\n\nDamit wird aus dem Repository gezielt das Produktionsartefakt erzeugt.<\/p>\n\n\n\n
Bei komplexeren Projekten w\u00e4re ein expliziter Build-Schritt noch sauberer.<\/p>\n\n\n\n
F\u00fcr ein klassisches PHP-WordPress-Theme reicht eine kontrollierte Synchronisation h\u00e4ufig aus.<\/p>\n\n\n\n
\n\n\n\nmain<\/code> automatisch deployen oder Releases verwenden?<\/h1>\n\n\n\nEin Push auf main<\/code> kann unmittelbar Produktion aktualisieren:<\/p>\n\n\n\non:\n push:\n branches:\n - main<\/code><\/pre>\n\n\n\nDas ist echtes Continuous Deployment.<\/p>\n\n\n\n
Der Ablauf:<\/p>\n\n\n\n
Commit\n \u2193\nPush main\n \u2193\nValidation\n \u2193\nDeployment\n \u2193\nProduction<\/code><\/pre>\n\n\n\nEine konservativere Variante verwendet Git-Tags:<\/p>\n\n\n\n
on:\n push:\n tags:\n - \"v*\"<\/code><\/pre>\n\n\n\nDann:<\/p>\n\n\n\n
git tag v1.4.0\ngit push origin v1.4.0<\/code><\/pre>\n\n\n\nDer Tag wird zum expliziten Release-Signal.<\/p>\n\n\n\n
Beide Modelle sind legitim.<\/p>\n\n\n\n
Die Entscheidung h\u00e4ngt davon ab, welche Bedeutung main<\/code> im Entwicklungsprozess hat.<\/p>\n\n\n\n
\n\n\n\nNoch eine Stufe weiter: GitHub Environments<\/h1>\n\n\n\n
GitHub unterst\u00fctzt Environments wie:<\/p>\n\n\n\n
development\nstaging\nproduction<\/code><\/pre>\n\n\n\nEin Deployment-Job kann explizit einem Environment zugeordnet werden:<\/p>\n\n\n\n
environment:\n name: production\n url: https:\/\/example.com<\/code><\/pre>\n\n\n\nDarauf lassen sich weitere Regeln aufbauen.<\/p>\n\n\n\n
Bei gr\u00f6\u00dferen Systemen entsteht daraus beispielsweise:<\/p>\n\n\n\n
Pull Request\n \u2502\n \u25bc\nCI\n \u2502\n \u25bc\nMerge\n \u2502\n \u25bc\nStaging\n \u2502\n \u25bc\nApproval\n \u2502\n \u25bc\nProduction<\/code><\/pre>\n\n\n\nF\u00fcr einen pers\u00f6nlichen WordPress-Blog kann das \u00fcberdimensioniert sein.<\/p>\n\n\n\n
Das zugrunde liegende Konzept bleibt trotzdem wichtig:<\/p>\n\n\n\n
\nDeployment-Ziele sind eigene Umgebungen mit eigenen Regeln und Secrets.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nWas diese Pipeline nicht l\u00f6st<\/h1>\n\n\n\n
Automatisierung sollte nicht mit Sicherheit verwechselt werden.<\/p>\n\n\n\n
Die beschriebene Pipeline sch\u00fctzt beispielsweise nicht automatisch vor:<\/p>\n\n\n\n
\n- semantischen PHP-Fehlern<\/li>\n\n\n\n
- fehlerhaftem CSS<\/li>\n\n\n\n
- kaputtem Responsive Design<\/li>\n\n\n\n
- JavaScript-Logikfehlern<\/li>\n\n\n\n
- falschen WordPress Queries<\/li>\n\n\n\n
- Datenbankproblemen<\/li>\n\n\n\n
- Plugin-Inkompatibilit\u00e4ten<\/li>\n\n\n\n
- \u00c4nderungen an WordPress-Inhalten<\/li>\n\n\n\n
- defekten externen Diensten<\/li>\n<\/ul>\n\n\n\n
Ein Theme kann alle Syntaxchecks bestehen und trotzdem visuell zerst\u00f6rt sein.<\/p>\n\n\n\n
Daf\u00fcr w\u00e4ren weitere Ebenen notwendig:<\/p>\n\n\n\n
Unit Tests\nIntegration Tests\nBrowser Tests\nVisual Regression Tests\nStaging\nMonitoring<\/code><\/pre>\n\n\n\nEine Pipeline muss nicht alles pr\u00fcfen.<\/p>\n\n\n\n
Sie sollte aber klar definieren, was ein gr\u00fcner Status bedeutet.<\/p>\n\n\n\n
In diesem Fall bedeutet er ungef\u00e4hr:<\/p>\n\n\n\n
\nDer erwartete Theme-Code ist vollst\u00e4ndig, syntaktisch valide, wurde auf das richtige Ziel synchronisiert und die wichtigsten WordPress-Seiten antworten danach ohne offensichtlichen Laufzeitfehler.<\/p>\n<\/blockquote>\n\n\n\n
Das ist bereits erheblich st\u00e4rker als:<\/p>\n\n\n\n
\nDer Upload ist fertig.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nDer vollst\u00e4ndige Denkprozess<\/h1>\n\n\n\n
Am Anfang steht h\u00e4ufig dieses Modell:<\/p>\n\n\n\n
Ich habe ein WordPress-Theme.\n\nIch \u00e4ndere Dateien.\n\nDann lade ich sie hoch.<\/code><\/pre>\n\n\n\nDas f\u00fchrt fast automatisch zu einem dateizentrierten Prozess.<\/p>\n\n\n\n
Das bessere Modell lautet:<\/p>\n\n\n\n
Ich entwickle Software.\n\nDas Repository beschreibt einen definierten Zustand.\n\nDieser Zustand wird validiert.\n\nEin validierter Zustand wird deployt.\n\nDer vorherige Zustand wird gesichert.\n\nDas Deployment wird anschlie\u00dfend verifiziert.<\/code><\/pre>\n\n\n\nDaraus entsteht:<\/p>\n\n\n\n
Git Repository\n \u2502\n \u2502 Source of Truth\n \u25bc\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Validation \u2502\n\u2502 \u2502\n\u2502 PHP \u2502\n\u2502 JavaScript \u2502\n\u2502 Theme structure \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502\n \u25bc\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Deployment Guard\u2502\n\u2502 \u2502\n\u2502 SSH \u2502\n\u2502 Target check \u2502\n\u2502 rsync dry-run \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502\n \u25bc\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Backup \u2502\n\u2502 \u2502\n\u2502 Timestamp \u2502\n\u2502 Commit \u2502\n\u2502 Retention \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502\n \u25bc\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Deployment \u2502\n\u2502 \u2502\n\u2502 rsync \u2502\n\u2502 --delete \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502\n \u25bc\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Verification \u2502\n\u2502 \u2502\n\u2502 HTTP \u2502\n\u2502 HTML \u2502\n\u2502 Fatal errors \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n \u2502\n \u25bc\n Production<\/code><\/pre>\n\n\n\nGitHub Actions ist dabei nicht der entscheidende Teil.<\/p>\n\n\n\n
Auch GitLab CI\/CD, Jenkins, Azure DevOps oder ein anderes System k\u00f6nnten denselben Prozess abbilden.<\/p>\n\n\n\n
Die entscheidende Ver\u00e4nderung ist die Architektur des Entwicklungsprozesses.<\/p>\n\n\n\n
\n\n\n\nVom Theme-Upload zum Software-Deployment<\/h1>\n\n\n\n
Der Unterschied zwischen beiden Ans\u00e4tzen l\u00e4sst sich auf wenige Zeilen reduzieren.<\/p>\n\n\n\n
Vorher:<\/p>\n\n\n\n
Dateien \u00e4ndern\n \u2193\nDateien hochladen\n \u2193\nfertig<\/code><\/pre>\n\n\n\nNachher:<\/p>\n\n\n\n
\u00c4nderung\n \u2193\nGit\n \u2193\nValidierung\n \u2193\nDry Run\n \u2193\nBackup\n \u2193\nDeployment\n \u2193\nSmoke Test\n \u2193\nProduction<\/code><\/pre>\n\n\n\nDas wirkt f\u00fcr ein WordPress-Theme zun\u00e4chst nach viel Infrastruktur.<\/p>\n\n\n\n
Die einzelnen Bausteine sind jedoch klein.<\/p>\n\n\n\n
Ein PHP-Syntaxcheck kostet fast nichts.<\/p>\n\n\n\n
Ein SSH-Verbindungstest kostet fast nichts.<\/p>\n\n\n\n
Ein rsync --dry-run<\/code> kostet fast nichts.<\/p>\n\n\n\nEin Backup vor dem \u00dcberschreiben kostet wenig.<\/p>\n\n\n\n
Ein HTTP-Smoke-Test kostet wenige Sekunden.<\/p>\n\n\n\n
Zusammen ver\u00e4ndern diese kleinen Guardrails die Eigenschaft des gesamten Prozesses.<\/p>\n\n\n\n
Das Theme liegt nicht mehr einfach auf einem Webserver.<\/p>\n\n\n\n
Es besitzt einen nachvollziehbaren Lebenszyklus.<\/p>\n\n\n\n
Und genau das sollte f\u00fcr ein WordPress-Theme genauso selbstverst\u00e4ndlich sein wie f\u00fcr jede andere Software.<\/p>\n","protected":false},"excerpt":{"rendered":"
Ein selbst entwickeltes WordPress-Theme ist Software. Es enth\u00e4lt PHP, JavaScript, CSS, Templates, Assets und Konfiguration. \u00c4nderungen an einer Datei k\u00f6nnen Auswirkungen auf andere Teile des Systems haben. Fehler k\u00f6nnen die komplette Website unbrauchbar machen. Trotzdem werden WordPress-Themes erstaunlich oft anders behandelt als andere Software: Oder noch direkter: F\u00fcr kleine \u00c4nderungen funktioniert das erstaunlich lange. Bis […]<\/p>\n","protected":false},"author":1,"featured_media":392,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,57,25,58,59],"tags":[],"class_list":["post-391","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-automation","category-infrastructure","category-software-engineering","category-ssh-remote-access","category-system-engineering"],"_links":{"self":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/391","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=391"}],"version-history":[{"count":1,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/391\/revisions"}],"predecessor-version":[{"id":393,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/posts\/391\/revisions\/393"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=\/wp\/v2\/media\/392"}],"wp:attachment":[{"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=391"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=391"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabricioruch.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=391"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}