🎯 Environments X Doppler¶

🚀 Démarrage Rapide¶

# 1. Installer Doppler CLI
brew install dopplerhq/cli/doppler

# 2. Se connecter
doppler login

# 3. Lancer un projet avec Doppler (spécifier projet et config)
doppler run -p api -c dev_local -- pnpm dev:api
doppler run -p front-app -c dev_local -- pnpm dev:webapp
doppler run -p front-mobile-app -c development_local -- pnpm dev:mobile
doppler run -p app-pdp-financement -c dev_local -- pnpm dev:app-pdp-financement

⚠️ Les fichiers .env ne sont plus supportés. Toutes les variables d'environnement passent par Doppler. Ne jamais écrire de tokens en dehors de Doppler.

🔍 Qu'est-ce que Doppler ?¶

Doppler est une plateforme de gestion des secrets et des variables d'environnement qui centralise et sécurise l'accès aux configurations sensibles de vos applications. Elle permet de :

🔒 Centraliser toutes les variables d'environnement dans un seul endroit
🛡️ Sécuriser l'accès aux secrets avec des permissions granulaires
🔄 Synchroniser automatiquement les variables entre les environnements
📊 Auditer les accès et modifications des secrets
🔗 Intégrer facilement avec les plateformes de déploiement (Heroku, GitHub Actions, etc.)

💻 Utilisation en Local¶

📦 Installation de Doppler CLI¶

# Installation via Homebrew (macOS)
brew install dopplerhq/cli/doppler

# Ou via curl
curl -Ls --tlsv1.2 --proto "=https" --retry 3 https://cli.doppler.com/install.sh | sh

# Vérification de l'installation
doppler --version

⚙️ Configuration locale¶

⚠️ Important : Les fichiers .env ne sont plus utilisés. Toutes les variables d'environnement sont injectées par Doppler via doppler run.

# Authentification avec Doppler (une seule fois)
doppler login

🏗️ Lancer un projet¶

Préfixer la commande de dev avec doppler run -p <projet> -c <config> -- :

# API
doppler run -p api -c dev_local -- pnpm dev:api

# Front-app
doppler run -p front-app -c dev_local -- pnpm dev:webapp

# App mobile
doppler run -p front-mobile-app -c development_local -- pnpm dev:mobile

# App PDP financement
doppler run -p app-pdp-financement -c dev_local -- pnpm dev:app-pdp-financement

💡 Recommandation : Utilisez l'environnement dev_personal qui est une copie de dev que vous pouvez modifier sans affecter les autres développeurs. Ou utilisez un des autres forks de dev qui peuvent déjà être partagées!

❌ Les fichiers `.env` ne sont plus supportés¶

Avant	Maintenant
`doppler secrets download > .env && pnpm dev`	`doppler run -p api -c dev_local -- pnpm dev:api`
Fichier `.env` dans chaque projet	Aucun fichier `.env`
`dotenv` en dépendance (API)	Supprimé

🏢 Structure des Projets Doppler¶

1. 🌐 Project Web (Front-end)¶

🌍 Environnements :

🟢 dev - Variables pour l'environnement de développement
🟢 dev_local - à utiliser pour le dev local
🟡 staging - Variables pour l'environnement de staging
🔴 production - Variables pour l'environnement de production

🔄 Synchronisation :

Les variables sont automatiquement synchronisées vers les GitHub Secrets
Utilisées dans les workflows de déploiement front-end et accessibles via ${{ secrets.* }} dans les GitHub Actions

2. 🔧 Project API¶

🌍 Environnements :

🟢 dev - API de développement
🟢 dev_local - Config à utiliser pour lancer l'API en local
🟢 dev_local_fork-prod - Config à utiliser pour lancer l'API en local avec un fork de BDD de prod
🟡 staging - API de staging
🔴 production - API de production

🔄 Synchronisation :

Les variables sont automatiquement synchronisées vers les config vars Heroku
Utilisées au runtime & Accessibles via process.env.* dans l'application

Checkout.com (`project api`)¶

Variable	Requis	Défaut si absent	Usage
`CHECKOUT_API_URL`	Oui	—	Base URL API Checkout (sandbox vs prod). Source : Developers → Overview ou Settings → Account details dans le dashboard de l'environnement.
`CHECKOUT_DASHBOARD_URL`	Oui	—	URL de base du dashboard Checkout pour les liens Slack ops (`sendDoublePaymentAlert`, `sendDisputeReceivedAlert`). Doit correspondre au même environnement que `CHECKOUT_API_URL` (sandbox en `dev` / `staging` / `dev_local`, prod en production).
`CHECKOUT_SECRET_API_KEY`	Oui	—	Clé secrète API Checkout.
`CHECKOUT_PROCESSING_CHANNEL_ID`	Oui	—	Processing channel Checkout.
`CHECKOUT_API_KEY_INTERNAL`	Oui (prod)	—	Clé `x-api-key` pour les webhooks Checkout entrants.
`CHECKOUT_TIMEOUT_IN_SECONDS`	Oui	—	Timeout HTTP client Checkout.

Doc métier : checkout.md (sections alertes Slack).

3. 🚀 Project API - CI¶

🌍 Environnements :

🔵 base - à ne pas utiliser directement c'est une config heritée par les autres
🔵 dev - Utilisée pour le deploy API dev
🔵 stg - Utilisée pour le deploy API Staging
🔵 prd - Utilisée pour le deploy API Prod et les check / validate de migrations
🔵 load-test - Utilisée pour le workflow de load-test uniquement

📦 Registre d'images (api-release-*.yml) :

Variable	Usage
`DOCKERHUB_USERNAME` / `DOCKERHUB_TOKEN`	Org access token Docker Hub `brickssas`, scopes Image Pull + Push sur `brickssas/bricks-api`. Push du build, pull et retag dans le job release.
`DOCKERHUB_PULL_TOKEN`	Org access token Image Pull seul, sur le même compte `brickssas`, transmis à Railway (`registryCredentials`) pour tirer l'image privée. Railway le stocke durablement : il ne doit jamais pouvoir pousser.
`RAILWAY_TOKEN`	Project token Railway lié à un environnement : il détermine dev ou prod, le pipeline vérifie le nom.
`RAILWAY_*_SERVICE_ID`	Plus lus par aucun workflow : `api-release-env.yml` résout les services par nom dans l'environnement du token. À supprimer.

Requises dans dev et prd. Les deux envs GitHub prod doivent les recevoir : API Prod (release) et API Prod no validation (preflight, tire l'image avant l'approbation).

🔄 Synchronisation :

Les variables sont automatiquement synchronisées vers les GitHub Secrets
Utilisées dans les workflows de CI/CD de l'API & Accessibles via ${{ secrets.* }} dans les GitHub Actions

4. 📱 Project Mobile¶

Note : The Doppler config slug is developement (not development) — this is the actual name in Doppler.

🌍 Environnements :

🟣 developement - Builds de developement
🟣 development_local - Dev local. (API Url notamment)
🟡 preview - Builds de preview
🔴 production - Builds de production
🔵 ci - Variables pour les builds CI/CD mobile (token expo)

🔄 Synchronisation :

Pas encore de synchronisation automatique Doppler → Expo
Il faut donc ajouter à la main sur les deux plateforme un nouveau token.
CI est synchronisé avec Github et permet notamment d'acceder au token Expo depuis github actions

🚀 Impact CI - Nouveau Système de GitHub Secrets¶

🔐 Compartimentation par Environnement¶

Avec Doppler, les GitHub Secrets sont maintenant compartimentés par environnement. Chaque workflow doit explicitement spécifier l'environnement GitHub à utiliser pour accéder aux bonnes variables.

⚙️ Configuration des Workflows¶

❌ Avant (ancien système)¶

- name: Build Front App
  env:
    API_URL: ${{ secrets.API_URL }}
    GTM_ID: ${{ secrets.GTM_ID }}
  run: yarn build

✅ Après (nouveau système avec Doppler)¶

jobs:
  build:
    runs-on: ubuntu-latest
    environment: Front Prod # ← Spécification de l'environnement
    steps:
      - name: Build Front App
        env:
          API_URL: ${{ secrets.API_URL }}
          GTM_ID: ${{ secrets.GTM_ID }}
        run: yarn build

🎯 Environments X Doppler¶

🚀 Démarrage Rapide¶

🔍 Qu'est-ce que Doppler ?¶

💻 Utilisation en Local¶

📦 Installation de Doppler CLI¶

⚙️ Configuration locale¶

🏗️ Lancer un projet¶

❌ Les fichiers .env ne sont plus supportés¶

🏢 Structure des Projets Doppler¶

1. 🌐 Project Web (Front-end)¶

2. 🔧 Project API¶

Checkout.com (project api)¶

3. 🚀 Project API - CI¶

4. 📱 Project Mobile¶

🚀 Impact CI - Nouveau Système de GitHub Secrets¶

🔐 Compartimentation par Environnement¶

⚙️ Configuration des Workflows¶

❌ Avant (ancien système)¶

✅ Après (nouveau système avec Doppler)¶

❌ Les fichiers `.env` ne sont plus supportés¶

Checkout.com (`project api`)¶