Si votre projet fonctionne bien dans l’espace de travail Replit et commence à signaler dès la publication des variables d’environnement manquantes, des clés d’API vides et des adresses de base de données inexistantes, ce type de problème ne vient généralement pas du code cassé lorsque l’environnement est modifié, mais plutôt du fait que l’environnement de déploiement n’hérite pas automatiquement de tout ce qui se trouve dans l’espace de travail comme vous le souhaitez.
Le conseil le plus important dans la documentation actuelle de Replit est que les secrets de production et les variables d’environnement dans le panneau Déploiements doivent être vérifiés en premier lors de la publication des numéros. Beaucoup de gens ne confirment que le programme peut fonctionner dans Workspace, et que l’environnement de release par défaut aura la même valeur, pour découvrir que l’environnement de production n’est plus disponible du tout après la mise en ligne.
Ce puits est particulièrement sujet à deux situations. Premièrement, vous avez temporairement défini des variables d’environnement dans le shell de l’espace de travail ou un processus de débogage, mais pas dans les Secrets officiels. Ensuite, quelqu’un dans votre équipe peut voir les valeurs dans son espace de travail, mais la cible de déploiement n’a pas ces configurations, créant l’illusion que « je suis bien ici, mais pas en ligne ».
Il est recommandé de l’organiser ainsi :
1. Lister toutes les variables d’environnement sur lesquelles le programme doit s’appuyer pour fonctionner.
2. Vérifiez les configurations Secrets et Deployments une par une, pas seulement pour voir si l’espace de travail existe.
3. Après le déploiement, utilisez des journaux ou des sorties pour confirmer quelles valeurs sont lues dans l’environnement actuel.
4. Si la logique doit distinguer entre développement et production, alors utilisez explicitement des variables environnementales telles que REPLIT_DEPLOYMENT pour la diversion conditionnelle.
Replit s’est aussi récemment orienté vers « déployer Secrets pour mieux synchroniser avec les secrets de l’espace de travail », mais cela ne signifie pas que vous pouvez sauter la vérification du tout. En particulier, les projets anciens, les projets migrés et les projets de collaboration multi-personnes ont le plus souvent un état semi-synchrone où « un côté a de la valeur et l’autre non ».
Par conséquent, il peut s’exécuter dans l’espace de travail, mais il manque de variables d’environnement après la sortie, donc ne blâme pas d’abord la compatibilité du framework. Vérifier séparément les environnements Secrets et Deployment est généralement plus rapide que de continuer à modifier le code.
