もしプロジェクトがReplitワークスペースでうまく動作し、リリース直後に環境変数の欠落、空のAPIキー、存在しないデータベースアドレスを報告し始める場合、この種の問題は通常、環境変更時にコードが壊れているのではなく、デプロイ環境がワークスペース内のすべてを自動的に継承しないことにあります。
現在のReplitドキュメントで最も重要なポイントは、問題を公開する際にデプロイメントパネルの本番秘密と環境変数をまず確認することです。 多くの人は、プログラムがWorkspaceで動作可能であること、そしてデフォルトのリリース環境も同じ値を持つことを確認し、本番環境が稼働した後は全く利用できないことがわかります。
このピットは特に二つの状況に陥りやすい。 まず、ワークスペースシェルやデバッグプロセスで一時的に環境変数を設定していますが、公式のSecretsには設定していません。 次に、チームの誰かは自分のワークスペースの値を見ることができますが、デプロイメントターゲットにはこれらの設定がないため、「ここでは問題ないけどオンラインではない」という錯覚が生まれます。
このように配置することをお勧めします:
1. プログラムが動作するために依存しなければならないすべての環境変数を一覧化する。
2. シークレットとデプロイメントの設定を一つずつ確認し、ワークスペースが存在するかどうかを確認するためだけに確認してください。
3. 展開後、ログや出力を使って現在の環境でどの値を読み取ったか確認します。
4. ロジックが開発と生産を区別する必要がある場合は、条件付き転用にREPLIT_DEPLOYMENTなどの環境変数を明示的に用いてください。
Replitは最近「ワークスペースのシークレットとより良く同期するためにSecretsを展開する」方向に進んでいますが、それはチェックを省略できるという意味ではありません。 特に、古いプロジェクト、移行されたプロジェクト、複数人の共同作業プロジェクトは、「一方には価値があり、もう一方にはない」という半同期的な状態を持つ可能性が高いです。
したがって、ワークスペース内で動作することは可能ですが、リリース後に環境変数が不足しているため、まずフレームワークの互換性を理由にしないでください。 シークレット環境とデプロイ環境を別々にチェックする方が、コード変更を続けるよりも通常は速いです。
