Partager les variables d'un projet
Où vivent les variables d'un projet Fraza en équipe, du poste de développement à la production, et comment partager les secrets sans les mettre dans git.
Un projet Fraza a trois sortes de valeurs : celles du poste de développement, celles de la production, et les secrets. Chacune a sa place, et aucun secret ne passe par git.
Qui a besoin de quoi
| Personne | Besoin | Où le trouver |
|---|---|---|
| Développeur | Faire tourner le site sur son poste | .env.example, copié en .env.local |
| Développeur qui touche à un service tiers | Des clés de test : Stripe en mode test, Resend de développement | Le coffre du projet, fiche « dev » |
| Responsable du déploiement | Les valeurs et les secrets de production | Le coffre du projet, fiche « production », et la plateforme d'hébergement |
Un développeur n'a pas besoin des secrets de production. S'il en a besoin, c'est souvent qu'il travaille contre la vraie base au lieu de la sienne. La personne qui a accès à la production peut le faire, en écrivant ces valeurs dans son .env.local : voir Développer avec les données de production.
Sur le poste : .env.example et .env.local
| Fichier | Suivi par git | Contenu |
|---|---|---|
.env.example | Oui | Toutes les variables du projet. Les valeurs locales, qui ne fonctionnent que sur localhost, y sont écrites. Les secrets y restent vides. |
.env.local | Non | La copie du poste, avec ses secrets. |
Un collègue qui clone le projet lance npm run dev, qui copie .env.example en .env.local avec une clé de chiffrement neuve, et le site tourne. Il n'ajoute, au besoin, que les clés de test prises dans le coffre.
Une variable ajoutée au projet s'ajoute aux deux fichiers : avec sa valeur dans .env.local, et dans .env.example avec sa valeur locale si elle n'est pas secrète, vide sinon. C'est l'oubli de cette étape qui laisse un collègue avec un projet qui ne démarre pas.
Une adresse locale comme postgres://fraza@localhost:5432/fraza?sslmode=disable n'est pas un secret : elle ne mène nulle part ailleurs que sur le poste. Un mot de passe de base, une clé d'API ou FRAZA_ENCRYPTION_KEY en sont un, même de test. npx fraza-doctor refuse un fichier suivi par git qui en porte.
En production : la plateforme d'hébergement
Les variables de production se saisissent dans la plateforme, Coolify par exemple, qui les passe au processus. Elles l'emportent toujours sur les fichiers. Voir Déploiement.
Tout le monde dans l'équipe n'a pas accès à la plateforme, et c'est voulu : seules les personnes qui déploient y vont.
Les secrets : un coffre partagé
Le gestionnaire de mots de passe de l'équipe est la référence pour les humains : Bitwarden, 1Password ou un équivalent.
- Un coffre par client ou par projet, avec deux fiches : « dev » pour les clés de test, ouverte aux développeurs du projet, et « production », réservée aux deux ou trois personnes qui déploient.
- La plateforme reçoit ses valeurs depuis le coffre. Elle ne fait que les exécuter.
- Une personne qui quitte l'équipe perd l'accès au coffre. Les secrets de production qu'elle a pu voir se changent ensuite, ce qui reste simple quand peu de personnes y ont accès.
FRAZA_ENCRYPTION_KEY doit être dans le coffre. Elle ne change jamais : la perdre rend illisibles les données chiffrées avec elle. La plateforme ne suffit pas comme seule copie, puisqu'un changement d'hébergeur la ferait disparaître. Voir Chiffrer des secrets.
Ce qu'on ne fait pas
- Committer un
.envavec des secrets, même dans un dépôt privé : tout lecteur du dépôt, et tout son historique, les garde. - Envoyer un secret par courriel ou par messagerie : il y reste lisible pour toujours.
- Copier la base de production sur un poste pour reproduire un bug : c'est copier des renseignements personnels, avec les obligations de la Loi 25. Des données de démonstration font l'affaire.