Intégrer à des flux de travail multi-environnements

Découvrez comment prendre en charge des flux de travail à plusieurs locataires et à plusieurs environnements lors de l’utilisation d’Auth0 Deploy CLI.

Auth0 Deploy CLI permet de travailler dans un contexte à plusieurs locataires et à plusieurs environnements. Lorsqu’il est intégré à vos flux de travail de développement CI/CD, il peut servir à propager les modifications apportées à Auth0, du développement de fonctionnalités jusqu’à la production.

En général, le flux de travail recommandé est le suivant :

1. Créez un locataire Auth0 distinct pour chaque environnement (développement, préproduction, production).
2. Créez un dépôt unique de fichiers de configuration des ressources pour tous les environnements.
3. Ajoutez une étape à votre pipeline CI/CD qui, lors du déploiement vers les environnements, applique les configurations des ressources Auth0 au locataire Auth0 approprié.

​

Locataire par environnement

Il est recommandé d’avoir un locataire/compte Auth0 distinct pour chacun de vos environnements. Par exemple :

Environnement	Locataire
Développement	travel0-dev
Test	travel0-uat
Préproduction	travel0-stage
Production	travel0-prod

​

Dépôt de configuration des ressources

Une fois exporté, l’état de votre locataire Auth0 sera représenté par un ensemble de fichiers de configuration des ressources, soit au format YAML ou sous forme de répertoire. Dans un contexte à environnements multiples, on s’attend à ce qu’un seul dépôt de configurations des ressources soit utilisé pour tous les environnements. En pratique, il peut s’agir d’un répertoire dans le code source de votre projet ou d’un code source entièrement distinct.

Vous devriez avoir au moins une branche par locataire dans votre dépôt, ce qui vous permet d’apporter des changements sans les déployer. Ainsi, les changements ne seront déployés 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 changements dans l’environnement ciblé chaque fois que la branche principale reçoit des mises à jour.

Votre flux de travail pourrait ressembler à ceci :

1. Apportez des changements à l’environnement de développement.
2. Fusionnez les changements vers l’environnement de test (ou uat).
3. Testez les changements dans uat. Lorsque tout est prêt, déplacez-les et fusionnez-les vers l’environnement de préproduction.
4. Testez la préproduction. Lorsque tout est prêt, déplacez-les et fusionnez-les vers l’environnement de production.

Par mesure de précaution, vous pouvez configurer votre environnement de production pour qu’il se déploie uniquement lorsqu’il est 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), puis déployées progressivement dans tous les autres environnements jusqu’à la production. Cette approche unidirectionnelle garantit des tests et des approbations suffisants pour les modifications apportées à votre locataire. Une fois ce processus établi, il est recommandé de ne pas appliquer directement des configurations en production par d’autres moyens, comme le Auth0 Dashboard ou la Management API, à moins que ces modifications ne soient consignées dans une exportation ultérieure de Deploy CLI. Sinon, elles 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 définies à l’aide de fichiers de configuration de l’outil distincts et du remplacement dynamique de mots-clés.

​

Fichiers de configuration distincts

L’utilisation d’un fichier de configuration d’outil distinct pour chaque environnement permet de garder les fichiers de configuration des ressources indépendants de l’environnement, tout en répondant aux besoins de chacun. Au minimum, vous devrez fournir des identifiants distincts pour chaque environnement, mais vous pouvez aussi exclure certaines ressources, activer la suppression et effectuer un remplacement dynamique de mots-clés selon l’environnement.

​

Exemple d’arborescence de fichiers

project-root
│
└───auth0
│   │   config-dev.json   # Fichier de config env Dev
│   │   config-test.json  # Fichier de config env Test
│   │   config-prod.json  # Fichier de config env Prod
│   │   ... tous les autres fichiers de configuration des ressources
│
└───src
    │   ... le code de votre projet

​

Valeurs dynamiques avec remplacement de mots-clés

Une fois des fichiers de configuration distincts utilisés pour chaque environnement, le remplacement de mots-clés au moyen de la propriété de configuration AUTH0_KEYWORD_REPLACE_MAPPINGS permet de définir des valeurs de remplacement dynamiques selon l’environnement. Par exemple, il peut être nécessaire d’avoir un ensemble distinct d’origines autorisées pour vos applications. Pour en savoir plus, consultez Remplacement de mots-clés.

​

Exemple de 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 de fichier 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"]
  }
}