Preflight und Self-hosted-Deployment-Bereitschaft

Self-hosted Preflight

Self-hosted bedeutet volle Kontrolle und damit auch volle Verantwortung. Vor jedem Run müssen nicht nur Formularwerte, sondern auch die Ausführungsumgebung validiert werden.

Zweck und Zielgruppe

Für Teams mit eigener Infrastruktur, die Wiederholbarkeit und starke Änderungskontrolle benötigen.

Voraussetzungen

• Server- und Netzwerkzugriff eingerichtet (SSH, Firewalls, DNS, Zertifikate),
• aktuelles Rollenmodell im Workspace und in der Plattform vorhanden,
• Template-Stack passt zur beabsichtigten Änderung,
• Rollback-Pfad ist dokumentiert und testbar.

Schritt-für-Schritt

1. Zielvalidierung: Serverzustand, Ports, DNS-Einträge und Repo-Erreichbarkeit prüfen.
2. SSH und Secrets: Schlüssel-/Credential-Paarung aktiv und über den Freigabeprozess erfasst prüfen.
3. Eingaben prüfen: alle Pflichtfelder vollständig ausfüllen und mit aktueller Vorlagenstruktur vergleichen.
4. Preflight ausführen: LaraDep-Check starten und Warnungen vor dem Run schließen.
5. Tag-Auswahl: für Baseline mit minimalem Tag-Set starten, Erweiterung erst nach erfolgreicher Validierung.
6. Nachprüfung: Erreichbarkeit, DNS, TLS und Run-Logs prüfen.

Prüf-Checkliste

• Ist die Zielumgebung vollständig verifiziert?
• Sind Rollen und Owner vor dem Start klar?
• Wurden Preflight-Warnungen bewertet?
• Gibt es einen Rollback-Pfad und einen validierenden Verantwortlichen?
• Ist eine Run-Notiz mit Grund und Ergebnis dokumentiert?

Häufige Fehler

• Start ohne Netzwerkvalidierung (DNS/Ports/Firewall),
• Vergessenes Update der Vorlage bei wiederkehrenden Änderungen,
• Changes außerhalb des Change-Fensters,
• unvollständig dokumentierter oder nicht getesteter Rollback.

Nächste Schritte

• Nach Baseline-Lauf gehen Sie zu Self-hosted täglichem Betrieb.
• Richten Sie Governance mit Self-hosted-Governance ein.
• Nutzen Sie bei Zwischenfällen Troubleshooting.

Nächster Schritt: Fahren Sie zur ersten Bereitstellung und Produktions-Checkliste.