52df6752d98d282bb723505f4d5d51ac6e6a7928
Das Go-live ist eine eigene Aufgabe, nicht der letzte Schritt des Staging-Deployments: oeffentlich, schwer umkehrbar, anderes Risiko. Phasen: Cutover-Modell waehlen; aufraeumen, was nicht mit auf live darf (DB-Dumps, Einmal-Skripte, .bak-Configs, Fehlerlogs); umgebungsabhaengige Konfiguration (trustedHostsPattern, displayErrors, site base, DB-Zugang, Mail); Staging-Sperren entfernen (Basic-Auth, noindex, Testkonten); Redirects/Scheduler/Sprachpakete/SSL; Verifikation und Rueckweg. Die Beispiele stammen aus einem realen Staging-Account: ~26 MB Dumps und Ticket-Sicherungen im Home, eine .bak-Config im Projektbaum, Basic-Auth in public/.htaccess, displayErrors=1 und ein auf die Staging-Domain gepinntes trustedHostsPattern. Die konsoleH-Deploy-Skill (jetzt 1.1) verweist am Ende darauf und benennt die beiden Artefakte, die sie selbst erzeugt und die nicht mitwandern duerfen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Description
No description provided
100 KiB
Languages
Markdown
100%