Wenn dein Projekt im Replit-Arbeitsbereich gut läuft und sofort nach der Freigabe fehlende Umgebungsvariablen, leere API-Schlüssel und nicht vorhandene Datenbankadressen meldet, liegt dieses Problem meist nicht daran, dass der Code bei der Änderung der Umgebung kaputt ist, sondern daran, dass die Bereitstellungsumgebung nicht automatisch alles im Arbeitsbereich so erbt, wie du es möchtest.
Der wichtigste Tipp in der aktuellen Replit-Dokumentation ist, dass die Produktionsgeheimnisse und Umweltvariablen im Deployments-Panel zuerst beim Veröffentlichen von Problemen überprüft werden sollten. Viele bestätigen nur, dass das Programm in Workspace ausgeführt werden kann und die Standard-Release-Umgebung denselben Wert hat, nur um festzustellen, dass die Produktionsumgebung nach dem Live-Start gar nicht mehr verfügbar ist.
Diese Grube ist besonders anfällig für zwei Situationen. Erstens hast du vorübergehend Umgebungsvariablen in der Workspace-Shell oder einem Debugging-Prozess gesetzt, aber nicht in den offiziellen Secrets. Zweitens kann jemand aus deinem Team die Werte in seinem Arbeitsbereich sehen, aber das Ziel, das Deployment-Ziel hat, hat diese Konfigurationen nicht, was die Illusion erzeugt, dass "ich bin hier in Ordnung, aber nicht online".
Es wird empfohlen, es so zu arrangieren:
1. Listen Sie alle Umweltvariablen auf, auf die sich das Programm zum Ausführen verlassen muss.
2. Überprüfen Sie die Secrets- und Deployments-Konfigurationen einzeln, nicht nur, um zu sehen, ob der Arbeitsbereich existiert.
3. Nach der Bereitstellung verwenden Sie Logs oder Ausgaben, um zu bestätigen, welche Werte in der aktuellen Umgebung gelesen werden.
4. Wenn die Logik zwischen Entwicklung und Produktion unterscheiden muss, dann verwenden Sie explizit Umweltvariablen wie REPLIT_DEPLOYMENT für bedingte Umleitung.
Replit hat sich kürzlich auch darauf konzentriert, "Secrets besser mit Workspace-Secrets zu synchronisieren", aber das heißt nicht, dass man das Überprüfen überhaupt überspringen kann. Insbesondere alte Projekte, migrierte Projekte und Mehrpersonen-Kollaborationsprojekte haben am ehesten einen halb-synchronen Zustand: "Eine Seite hat Wert, die andere nicht".
Daher kann es im Arbeitsbereich laufen, aber nach der Veröffentlichung fehlen Umweltvariablen, also gib nicht zuerst der Framework-Kompatibilität die Schuld. Das getrennte Überprüfen der Secrets- und Deployment-Umgebungen ist in der Regel schneller, als den Code weiter zu ändern.
