Bereit zum Deployen
Der Code kann jetzt deploybar sein, auch wenn noch kein Server existiert.
- Nachweis für Station 2
TiefeWarum „deploybar" ohne Server überhaupt entscheidbar ist
Es wirkt zunächst widersinnig, die Deploybarkeit zu behaupten, bevor es irgendwo zum Deployen gibt. Möglich ist es, weil alle vier Nachweise lokal prüfbar sind.
Das Dockerfile baut oder baut nicht — auf Ihrem Rechner mit demselben Docker, das oben läuft. Die .env.example ist vollständig oder nicht — src/env.js sagt es beim Start. Der Contract ist erfüllt oder nicht — dfx check sagt es. Der Stand ist committet oder nicht — git status sagt es.
Genau darum ist diese Reihenfolge gewählt: Station 02 vor Station 03. Wer zuerst den Server aufsetzt und dann feststellt, dass der Code nicht baut, sucht den Fehler an der unbequemsten Stelle — auf einem fremden Rechner, über SSH, in einem Build-Protokoll.
1Der Pre-Commit-Haken hat zwei Stufen. Welche greift immer, welche nur mit gitleaks?
.env im Commit? Nur mit gitleaks: Sehen Zeichenketten aus wie Schlüssel oder Passwörter? Deshalb lohnt sich die Installation — die erste Stufe fängt nur den offensichtlichsten Fall.2Es gibt noch keinen Server. Woran erkennen Sie trotzdem, dass der Code „deploybar" ist?
Dockerfile, das lokal gebaut wurde · eine vollständige .env.example · dfx check ohne offene Verstöße · ein committeter Stand. Danach ist das Veröffentlichen nur noch ein Formular mit vier Feldern.3dfx check zeigt bei Regel 4 ein !. Müssen Sie etwas beheben?
/healthz die Wahrheit sagt. Sie sehen selbst nach. Nur ✗ ist ein belegbarer Verstoß mit Fundstelle.