Passer au contenu principal
L’outil Deploy CLI prend en charge le travail dans un contexte multilocataire et multienvironnement. Lorsqu’il est intégré dans vos flux de production de développement CI/CD, peut être utilisé pour propager les modifications Auth0 du développement des fonctionnalités jusqu’à la production. En général, le flux de production conseillé est le suivant :
  1. Créer un locataire Auth0 distinct pour chaque environnement (développement, intermédiaire, production).
  2. Créer un référentiel unique de fichiers de configuration des ressources pour tous les environnements.
  3. Ajoutez une étape dans votre pipeline CI/CD lors du déploiement vers des environnements qui applique les configurations de ressources Auth0 au locataire Auth0 approprié.

​
Du locataire à l’environnement

Il est recommandé d’avoir un compte/locataire Auth0 distinct pour chaque environnement que vous avez. Par exemple :
EnvironnementLocataire
Développementtravel0-dev
Teststravel0-uat
Échelonnementtravel0-stage
Productiontravel0-prod

​
Référentiel de configuration des ressources

Lors de l’exportation, votre état de locataire Auth0 sera représenté sous forme d’un ensemble de fichiers de configuration de ressources, soit dans un format YAML ou répertoire. Dans un contexte multienvironnement, on s’attend à avoir un seul référentiel de configurations de ressources qui est appliqué à tous les environnements. En pratique, cela peut exister en tant que répertoire dans la base de code de votre projet ou dans une base de code séparée. Vous devriez avoir au moins une branche pour chaque locataire dans votre référentiel, ce qui vous permet d’apporter des modifications sans les déployer. De cette façon, les modifications ne seront déployées que lorsque vous fusionnerez la branche de travail dans la branche principale (comme main ou master). Avec cette configuration, vous pouvez avoir une tâche d’intégration continue pour chaque environnement qui déploie automatiquement les modifications à l’environnement ciblé chaque fois que la branche principale reçoit des mises à jour. Votre flux de production pourrait ressembler à ceci :
  1. Apporter des changements au développement.
  2. Fusionner les modifications apportées aux tests (ou uat).
  3. Tester les modifications en uat. Lorsque vous êtes prêt, déplacez et fusionnez les modifications à la simulation.
  4. Simulation. Lorsque vous êtes prêt, déplacez et fusionnez les modifications à la production.
Par précaution, vous pouvez configurer votre environnement de production pour le déployer uniquement lorsque déclenché manuellement.

​
Flux unidirectionnel

Le flux de travail multienvironnement fonctionne mieux lorsque les changements sont propagés « vers le haut » dans une seule direction. Les modifications apportées aux fichiers de configuration des ressources doivent d’abord être appliquées à l’environnement de niveau le plus bas (comme le développement) et ensuite être appliquées progressivement dans tous les autres environnements jusqu’à ce qu’elles soient appliquées à la production. Cette pratique unidirectionnelle garantit des tests et une approbation suffisants pour les changements apportés à votre locataire. Après avoir effectué la configuration, il est conseillé de ne pas appliquer les paramètres directement en production via Auth0 Dashboard ou Management API, sauf si ces changements ont été capturés par une exportation ultérieure de l’outil Deploy CLI. Autrement, ces modifications risquent d’être écrasées.

​
Valeurs propres à l’environnement

Bien qu’on s’attende à ce que tous les environnements partagent le même ensemble de fichiers de configuration des ressources, les valeurs propres à l’environnement peuvent être exprimées par des fichiers de configuration d’outils distincts et un Remplacement des mots clés dynamique.

​
Fichiers de configuration distincts

La spécification d’un fichier de configuration d’outil distinct par environnement peut être utilisé pour garder les fichiers de configuration des ressources indépendants de l’environnement, tout en prenant en charge les besoins de chaque environnement. Au minimum, vous devrez fournir des identifiants distinctes pour chaque environnement, mais il est également possible d’exclure certaines ressources, d’activer la suppression et d’effectuer un remplacement dynamique de mots clés par environnement.

​
Exemple de structure de fichier

project-root
│
└───auth0
│   │   config-dev.json   # Dev env config file
│   │   config-test.json  # Test env config file
│   │   config-prod.json  # Prod env config file
│   │   ... all other resource configuration files
│
└───src
    │   ... your project code

​
Valeurs dynamiques avec remplacement de mots-clés

Une fois que des fichiers de configuration distincts sont adoptés pour chaque environnement, le remplacement par mot clé via la propriété de configuration AUTH0_KEYWORD_REPLACE_MAPPINGS peut être utilisé pour exprimer les valeurs de remplacement dynamique en fonction de l’environnement. Par exemple, vous pourriez trouver nécessaire d’avoir un ensemble distinct d’origines autorisées pour vos clients. Pour en savoir plus, veuillez consulter Remplacement de mots-clés.

​
Exemple config-dev.json

{
  "AUTH0_DOMAIN": "travel0-dev.us.auth0.com",
  "AUTH0_CLIENT_ID": "PdwQpGy62sHcsV6ufZNEVrV4GDlDhm74",
  "AUTH0_ALLOW_DELETE": true,
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "ENV": "dev",
    "ALLOWED_ORIGINS": ["http://localhost:3000", "http://dev.travel0.com"]
  }
}

​
Exemple config-prod.json

{
  "AUTH0_DOMAIN": "travel0.us.auth0.com",
  "AUTH0_CLIENT_ID": "vZCEFsDYzXc1x9IomB8dF185e4cdVah5",
  "AUTH0_ALLOW_DELETE": false,
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "ENV": "prod",
    "ALLOWED_ORIGINS": ["http://travel0.com"]
  }
}