Files

T

clemens e4fa714419 Add go-live and go-to-market roadmaps

2026-06-15 17:52:08 +02:00

11 KiB

Raw Blame History

Go-Live-Checkliste fuer Netcup Webspace

Diese Checkliste ist fuer den ersten echten Betrieb auf Netcup Webspace gedacht. Sie baut auf DEPLOY.md, RUNBOOK.md und docs/production-blueprint.md auf, ist aber absichtlich strenger und operativer.

1. Go-Live-Scope festziehen

Entscheiden, ob der erste Livegang ein geschlossener Pilot oder ein oeffentliches SaaS-Launch ist.
Fuer einen oeffentlichen Launch Registrierung absichern oder vorerst deaktivieren. Das Repo nennt Mail-Verifikation, Passwort-Reset und Rate-Limits selbst als offene Punkte vor echtem Go-Live.
Falls diese Punkte noch fehlen: nur mit eingeladenen Testkunden oder manuell freigeschalteten Mandanten live gehen.
Einen Release-Owner und einen Restore-Owner benennen.
Ein Wartungsfenster fuer den Erststart und fuer kuenftige Releases definieren.

2. Environment-Modell festlegen

Empfehlung fuer Netcup Webspace:

local: Entwicklung lokal.
staging: echte Netcup-Subdomain wie staging.example.tld, eigene DB, eigene .env.
production: produktive Domain, eigene DB, eigene .env.

Pragmatisches Verzeichnislayout ohne Root-Zwang:

staging unter /apps/kaffeekasse-stage/current
production unter /apps/kaffeekasse/current
Offsite- oder Backup-Artefakte nicht im Webroot ablegen.

Wichtig fuer dieses Repo:

public/ bleibt der einzige Webroot.
.env wird aus dem Projektwurzelverzeichnis geladen.
Der Browser-Installer schreibt .env in das Projektwurzelverzeichnis und storage/installed.lock in storage/.
bin/cron.php schreibt storage/cron.lock.
Deshalb muessen Projektwurzel und storage/ mindestens fuer den Deployment-User, besser auch fuer den Webspace-User, sauber beschreibbar sein.

3. Netcup vorbereiten

Domain oder Subdomain im CCP/WCP anlegen.
DNS frueh setzen und Aufloesung pruefen.
In Plesk/WCP pro Environment eine eigene Site mit eigenem Document Root anlegen.
Document Root fuer jedes Environment auf .../current/public setzen.
Pro Environment eine eigene MySQL-Datenbank und einen eigenen DB-User anlegen.
PHP-Version im WCP fest auf 8.3 oder 8.4 pinnen und nicht auf "System Default" lassen.
Dieselbe PHP-Hauptversion fuer Web und CLI verwenden.

4. Secrets und Konfiguration vorbereiten

Pflichtwerte laut App:

APP_URL
APP_ENV
APP_DEBUG=0
APP_TIMEZONE
APP_KEY
DB_HOST
DB_PORT
DB_NAME
DB_USER
DB_PASS
RFID_SHARED_SECRET

Empfehlung:

staging und production nie dieselben Secrets oder dieselbe DB teilen.
Admin-Zugang fuer die Plattform separat dokumentieren und im Passwortsafe ablegen.
Wenn der Browser-Installer verwendet wird: danach .env sichern und offsite ablegen.
Wenn .env manuell gepflegt wird: .env vor dem ersten Deploy lokal erzeugen und erst dann hochladen.

5. Erstes Staging-Deployment

Lokal oder in CI scripts/build-release.sh ausfuehren.
Release-Artefakt sicher ablegen. Es ist Teil des Rollback-Pfads.
Artefakt per FTPES oder SFTP nach Netcup hochladen.
Paket in den festen Environment-Pfad entpacken.
Pruefen, dass .env, storage/uploads, storage/logs und storage/cache nicht versehentlich ueberschrieben oder geloescht wurden. Das Build-Skript schliesst diese Pfade aus dem Release aus.
Falls der Browser-Installer genutzt wird: /install nur auf staging einmal durchlaufen.
Falls manuell installiert wird: .env hochladen und danach /usr/local/php83/bin/php /apps/kaffeekasse-stage/current/bin/migrate.php oder die zu eurer PHP-Version passende Binary ausfuehren.
Pruefen, dass storage/installed.lock angelegt wurde.

6. Staging-Smoketest vor Production

Startseite laden.
/admin/login erfolgreich testen.
Einen Test-Mandanten anlegen.
Tenant-Login pruefen.
Eine Testbuchung und eine Test-Einzahlung anlegen.
/usr/local/php83/bin/php /apps/kaffeekasse-stage/current/bin/healthcheck.php ausfuehren und JSON pruefen.
/usr/local/php83/bin/php /apps/kaffeekasse-stage/current/bin/cron.php manuell ausfuehren.
Pruefen, dass cron.lock nach dem Lauf wieder verschwindet.

7. SSL und HTTPS

Erst SSL ausrollen, wenn DNS sauber auf Netcup zeigt.
Im WCP fuer jede produktive Domain ein Let's-Encrypt-Zertifikat ausstellen.
www nur dann mit absichern, wenn www auch wirklich genutzt werden soll.
Fuer den ersten Go-Live kein Wildcard-Zertifikat verwenden, wenn es nicht zwingend noetig ist. Bei Netcup werden Wildcard-Zertifikate nicht automatisch erneuert.
HTTPS fuer die produktive Domain erzwingen.
Nach Aktivierung pruefen, dass alle Logins und Formulare nur noch ueber HTTPS laufen.
Session-Cookies unter HTTPS pruefen, weil secure in der App vom HTTPS-Kontext abhaengt.

8. Backup-Strategie produktionsreif machen

Minimum:

Taegliches DB-Backup einrichten.
Vor jedem Release ein frisches manuelles DB-Backup ziehen.
.env offsite sichern.
storage/uploads offsite sichern.
Letztes stabiles Release-Artefakt offsite sichern.

Netcup-spezifisch:

Falls euer Tarif den Backup Manager anbietet: wiederkehrendes Backup in WCP aktivieren.
Backups regelmaessig herunterladen oder an einen zweiten Ort kopieren.
Backup Manager nicht als einzigen Disaster-Recovery-Pfad betrachten. Netcup dokumentiert, dass diese Backups nur auf demselben Hosting wiederhergestellt werden sollen.

9. Cron sauber einrichten

In WCP eine geplante Aufgabe fuer bin/cron.php alle 5 Minuten anlegen.
Dieselbe PHP-Version verwenden wie fuer die Website.
Den Task vor dem Speichern mit "Run Now" testen.
Wenn WCP auf eurem Tarif mit chroot oder relativen Pfaden zickt: den final funktionierenden Befehl direkt dokumentieren.
Eine zweite geplante Aufgabe fuer bin/healthcheck.php einrichten, mindestens stuendlich oder taeglich.
Task-Ausgaben in eine Mail oder Logdatei laufen lassen, statt sie still zu verwerfen.

Wichtige Einschraenkung dieses Repos:

bin/healthcheck.php liefert JSON, setzt aber bei DB-Problemen derzeit keinen expliziten Exit-Code ungleich 0.
Fuer Alarmierung deshalb nicht nur auf "Errors only" bei Scheduled Tasks vertrauen.
Zusaetzlich einen externen HTTPS-Uptime-Check auf Startseite oder Login-Seite einrichten.

10. Monitoring-Minimum fuer den Start

Externes Uptime-Monitoring auf die produktive HTTPS-URL aktivieren.
Plesk-/PHP-Error-Logs in die Regelbetriebsroutine aufnehmen.
Nach dem Go-Live taeglich Audit-Ereignisse fuer fehlgeschlagene Logins und Access-Denied pruefen.
Wachstum der Tabellen consumption_events, ledger_entries und audit_events beobachten.
Offene RFID-Ereignisse aus dem Cron-Output beobachten, falls RFID pilotiert wird.
Einen klaren Empfaenger fuer Alarmmails hinterlegen.

11. Release-Prozess fuer echte Produktion festlegen

Empfohlener erster Produktionsprozess auf Netcup Webspace:

Aenderungen auf staging komplett durchtesten.
Release-Artefakt mit Zeitstempel bauen.
Direkt vor dem Produktionsdeploy DB-Backup erstellen.
.env und persistente storage/-Inhalte zusatzlich sichern.
Release nach production hochladen.
bin/migrate.php ausfuehren.
bin/healthcheck.php ausfuehren.
Admin-Login, Tenant-Login und Testbuchung sofort pruefen.
Den naechsten automatischen Cron-Lauf beobachten.
Erst danach das Release als "stabil" markieren.

Wichtige Einschraenkung dieses Repos:

bin/migrate.php spielt nur database/schema.sql erneut ein.
Das aktuelle schema.sql arbeitet mit CREATE TABLE IF NOT EXISTS und ist damit fuer Erstinstallation geeignet, aber kein vollwertiges inkrementelles Migrationssystem.
Vor dem ersten Release mit DB-Schema-Aenderungen eine klare Migrationskonvention festlegen, zum Beispiel versionierte SQL-Dateien plus Runbook-Schritt.

12. Fallback und Restore vorher ueben

Rollback fuer einen fehlgeschlagenen Release:

Letztes stabiles Release-Artefakt erneut deployen.
Wenn noetig DB-Backup vom Start des Releases einspielen.
.env und storage/uploads wiederherstellen.
bin/healthcheck.php ausfuehren.
Admin-Login, Tenant-Login und Testbuchung pruefen.

Restore fuer echten Ausfall:

Zielreihenfolge dokumentieren: Code, .env, Uploads, DB, Healthcheck, Smoke-Test.
Restore nicht nur theoretisch planen, sondern einmal auf staging ueben.
Ziel-RTO und Ziel-RPO festlegen, auch wenn sie anfangs noch pragmatisch sind.
Ansprechpartner und Zugangsdaten fuer Restore ausserhalb des Repos dokumentieren.

13. Finale Go-Live-Freigabe

Nur live schalten, wenn alles abgehakt ist:

Production-Domain zeigt auf Netcup und loest korrekt auf.
SSL ist gueltig und HTTPS wird erzwungen.
public/ ist einziger Webroot.
.env, Backups, Dumps und .git sind nicht oeffentlich erreichbar.
DB-Backup von heute existiert.
Cron laeuft erfolgreich.
Externes Monitoring prueft die Seite.
Admin-Login und ein Test-Tenant funktionieren.
Restore wurde mindestens einmal auf staging geprobt.
Es gibt eine bewusste Entscheidung, ob offene Registrierung bereits verantwortbar ist.

11 KiB Raw Blame History