umairmsm/wp-ship

Stufe 7: Ship

Ziel: Staging spiegelt Live, jedes Deployment ist langweilig, der Launch-Tag hat einen Rollback, und die erste Woche wird überwacht.

Der Besitzer führt Deployments durch. Agenten bereiten vor, prüfen und erklären. Sie führen kein SSH auf Servern aus, starten kein deploy-safe.sh, ändern kein DNS und berühren kein Cloudflare, es sei denn, der Besitzer fordert genau diese Aktion an. deploy-safe.sh benötigt ein Terminal und eine eingegebene Commit-ID, daher kann ein Agent es nicht alleine abschließen.

Schritte

1. Staging (references/deploy-and-launch.md, „Staging“): eigener Ordner und eigene Datenbank auf dem Live-Host, WP_ENVIRONMENT_TYPE=staging, hinter Cloudflare Access, ein Test-Postfach für Anfragen.
2. Härten Sie jeden Server mit der projekteigenen docs/reference/DEPLOY_HARDENING.md. Dokumentieren Sie die Ergebnisse in docs/reference/SECURITY_PRELAUNCH.md.
3. Edge: Cloudflare-Einstellungen aus references/cloudflare-edge.md. Bevor Sie den Proxy vor einem alten Host aktivieren, testen Sie ihn: Einige Hosts begrenzen die Rate nach IP und blockieren Cloudflare.
4. Code bereitstellen, nur Besitzer:
   • Füllen Sie deploy/targets.conf aus dem Beispiel aus;
   • Führen Sie scripts/deploy-safe.sh <commit> --target staging --dry-run aus, lesen Sie die Änderungsliste, dann führen Sie es erneut ohne --dry-run aus;
   • Der erste Lauf auf einem Server, der bereits Code hat, benötigt --assume-live <commit>.
5. Inhalte separat bereitstellen.
   • Code enthält niemals Preise, Seiten oder rechtliche Texte.
   • Dokumentieren Sie jede Änderung als docs/data/content-changes/<date>-<topic>.json (Vorher-/Nachher-Werte pro Feld).
   • Wenden Sie es mit scripts/apply-content-change.sh <file> --target staging (Trockenlauf) an, dann mit --apply.
   • Führen Sie nach jedem Datenbankimport oder -umzug scripts/check-emoji.sh --target <env> aus.
6. Launch-Audit: Führen Sie den launch-auditor-Agenten gegen Staging aus, beheben Sie Fehler, und führen Sie ihn erneut aus, bis er bestanden wird.
7. Cutover-Plan. Schreiben Sie ihn aus references/deploy-and-launch.md, „Cutover“. Der Besitzer genehmigt Datum und Uhrzeit, und der Geschäftspartner ebenfalls, wenn die Seite bereits Buchungen annimmt.
8. Go live: Deployment auf Live, führen Sie launch-auditor gegen Live aus, reichen Sie die Sitemap bei der Search Console ein, senden Sie eine echte Testanfrage an das echte Postfach.
9. 7 Tage überwachen: Fehler, 404er (Redirects hinzufügen), das Formular-Postfach, Analytics, Search Console-Abdeckung.

Gate (in SITE_STATUS.md abhaken)

• Staging hinter Access, noindex, E-Mail geschützt
• Härtung angewendet und dokumentiert
• Sicheres Deployment auf Staging; Smoke-Test grün
• launch-auditor BESTANDEN auf Staging, dann auf Live
• Cutover-Plan genehmigt (Datum, Rollback, E-Mail/MX geprüft)
• 7-Tage-Überwachung abgeschlossen

Vorfälle, die diese Regeln geprägt haben

• Ein Agent änderte Live-Preise, veröffentlichte KI-geschriebene AGB und deployte ein Feature ohne Review, und sein Bericht ließ das Deployment aus. Seitdem: Deployments kommen nur von gemergten Commits, über das Skript, von einem Menschen eingegeben, und Produktions-SSH-Schlüssel verlangen bei jeder Verwendung eine Bestätigung.
• Das Kontaktformular auf Staging postete an einen Drittanbieter-Formulardienst mit einem Test-Schlüssel, so dass Anfragen in ein Test-Postfach gingen. Vor dem Launch eine echte Anfrage auf Live senden und prüfen, ob sie ankommt.
• Webanalyse im „Lite“-Modus zählte wochenlang keine EU-Besucher, was die Kernmärkte verbarg. Überprüfen Sie die Einstellungen am Tag 1.
• Ein langes Deployment (39 Commits) stoppte an einem SIGPIPE von git log | head unter pipefail. Das Skript erfasst nun die Ausgabe zuerst.
• Ein Server-Datenbankimport verwandelte Emojis in ????. Führen Sie check-emoji.sh nach jedem Import aus.