Aller au contenu principal

Utiliser les variables

Syntaxe​

Une référence de variable s'écrit entre ${ et }, préfixée par son scope :

SyntaxeCible
${var.env.NOM}Une variable du projet, par sa clé ; la valeur utilisée est celle de l'environnement d'exécution
${var.projet.Groupe.Nom}Une variable du projet, par son chemin groupe.nom
${var.company.NOM}Une variable d'organisation

Dans le panneau de réglages d'une brick, il suffit de taper ${ dans un champ texte : un autocomplete liste les variables disponibles (groupées par scope). La référence insérée s'affiche comme un badge typé (ENV, PROJET, COMPANY) ; un clic sur la croix revient à une valeur littérale.

Dans les configurations de bricks​

La référence peut être la valeur entière d'un champ, ou être noyée dans une chaîne plus large (requête SQL, URL, code Python, message d'alerte…).

Chemins de fichiers​

/data/${var.env.REGION}/export.csv

Requêtes SQL​

SELECT * FROM orders
WHERE order_date >= '${var.env.DATE_DEBUT}'
  AND status = '${var.projet.Import.STATUT}'

URLs d'API​

https://${var.env.API_HOST}/v1/orders?limit=${var.env.LIMITE}

Code Python​

url = "${var.env.API_HOST}"
df = df[df["region"] == "${var.env.REGION}"]

Les champs numériques acceptent aussi une référence ${...} à la place d'un nombre.

Résolution à l'exécution​

Les références sont résolues au lancement du run, jamais figées dans le pipeline :

  • exécution sur un environnement (« Lancer maintenant », workflows) : la valeur est celle de cet environnement ; si l'environnement ne la surcharge pas, la valeur par défaut du projet s'applique ;
  • exécution en Studio (copie de travail) : les valeurs du projet s'appliquent ;
  • les variables secrètes sont déchiffrées uniquement pour le runner, au moment de l'exécution.

Un même pipeline, déployé de dev à prod, change donc de configuration sans aucune modification : seules les valeurs portées par l'environnement diffèrent ; voir Environnements et déploiement.

Exemple de bout en bout​

  1. Variable DB_SCHEMA définie au projet, défaut public ;
  2. l'environnement prod surcharge DB_SCHEMA avec sales_prod ;
  3. la brick Source base de données utilise ${var.env.DB_SCHEMA} dans sa requête ;
  4. en Studio le run lit public ; lancé sur prod, il lit sales_prod.

Bonnes pratiques​

  • Référencez une variable partout où une valeur dépend de l'environnement (hôtes, chemins, schémas, limites) ;
  • préférez des clés explicites en SNAKE_CASE majuscule (API_HOST, DATE_DEBUT) ;
  • vérifiez la zone Variables référencées de l'onglet Connexion d'une brick pour voir d'un coup d'œil ce qu'elle consomme.