Environnements

BlockLucky tourne dans quatre configurations. Elles partagent le même code ; seules changent la façon de lancer les processus, la configuration et la blockchain visée.

#Développement local

Les dépendances tournent dans Docker, les applications sur le poste. C'est le mode décrit dans Infrastructure locale et Lancer les applications.

docker compose up -d --wait

Cette commande démarre postgres (port 5434), redis (6380), mailpit (1025 et 8025) et blockchain (8545), tous liés à 127.0.0.1. Chaque application lit ensuite son propre fichier .env, copié depuis .env.example :

Particularités de ce mode :

• en development, le backend accepte les valeurs par défaut des secrets, la désactivation de LOGIN_EMAIL_CODE_REQUIRED, ADMIN_MFA_REQUIRED et AGE_VERIFICATION_REQUIRED, et BLOCKCHAIN_MODE=simulated ;
• RUN_WORKERS=true par défaut : un seul processus npm run dev porte l'API, les workers BullMQ, l'indexeur et le keeper ;
• les journaux sont colorés et lisibles, au niveau debug ;
• /metrics et le détail de /health/deep sont accessibles sans jeton si METRICS_TOKEN est vide ;
• le compte opérateur est le compte Hardhat n° 0, qui a déployé les contrats et garde les rôles opérateur, pause, frappe et DEFAULT_ADMIN_ROLE ; l'administrateur de la Mairie est le compte n° 2, la trésorerie le compte n° 1.

Le mode simulé (BLOCKCHAIN_MODE=simulated) permet de travailler sans nœud : achats, tirages et badges sont alors fabriqués par blockchain.service.ts avec des hachages aléatoires. Il est refusé en production. Voir Mode onchain ou simulé.

#Stack Docker

Toute l'application tourne en conteneurs sur le poste, avec les mêmes images que celles visées en production :

docker compose --profile app up -d --build --wait

Ce qui change par rapport au développement local :

Les détails sont dans Docker Compose et Stack complète en conteneurs.

#Démonstration en ligne

La démonstration publique vise etherbay.tech, sur une machine virtuelle Azure for Students. Elle reprend la stack Docker avec quatre différences : des URL publiques en HTTPS derrière le proxy Caddy, la prise en compte du proxy (TRUST_PROXY), des ports applicatifs limités à 127.0.0.1 et un nœud Hardhat qui tourne sur la VM. À la date de rédaction, la VM et Caddy sont en place, l'application n'est pas encore déployée.

La procédure complète, avec la liste de ce qui reste à faire, est dans Déploiement sur etherbay.tech.

#Sepolia

Sepolia est le réseau de test public d'Ethereum. C'est le seul environnement où le tirage utilise le vrai service Chainlink VRF v2.5 et où les transactions sont visibles par tous sur un explorateur. Les ethers y sont gratuits mais rares (robinets limités), ce qui change l'exploitation : le compte opérateur paie le gas du keeper, des badges et de chaque dotation de bienvenue.

La mise en place passe par quatre scripts de smart-contract/, à lancer dans l'ordre : npm run vrf:sepolia crée et finance l'abonnement VRF, npm run deploy:sepolia vérifie le réseau, la key hash et le financement, déploie les deux contrats, répartit les rôles entre le multisig de la Mairie (MAIRIE_ADMIN_ADDRESS), la trésorerie (MAIRIE_TREASURY_ADDRESS) et l'opérateur (OPERATOR_ADDRESS), puis écrit deployments/sepolia.json (fichier non versionné) ; npm run automation:sepolia inscrit l'upkeep Chainlink Automation et npm run verify:sepolia publie le code sur Etherscan. Aucun de ces scripts n'a encore été exécuté : ils demandent les clés et les fonds de test de l'équipe, et aucune adresse Sepolia n'est enregistrée dans le dépôt. La procédure est détaillée dans Déploiement sur Sepolia et Redéployer sur Sepolia.

Côté backend, les variables à changer par rapport à la stack locale :

CHAIN_START_BLOCK évite de parcourir toute la chaîne depuis le bloc 0 au premier démarrage de l'indexeur. CHAIN_CONFIRMATIONS fait attendre l'indexeur deux blocs sous la tête de chaîne, ce qui protège contre une réorganisation courte. Ces mécanismes sont décrits dans Indexeur d'événements.

#Ce qui ne change jamais

Quel que soit l'environnement :

• le schéma de configuration de env.config.ts valide toutes les variables au démarrage et arrête le processus si l'une est invalide ;
• les migrations Prisma sont appliquées par prisma migrate deploy, jamais par migrate dev, hors poste de développement ;
• la source de vérité des tickets, tirages et cagnottes est le smart contract ; PostgreSQL n'en est qu'une projection reconstruisible (voir Reconstruire depuis la chaîne) ;
• les comptes de démonstration ne sont créés que par le seed (npm run prisma:seed), lancé à la main.