Intégrer à des flux de travail multi-environnement

Découvrez comment prendre en charge des flux de travail multi-locataires et multi-environnement lorsque vous utilisez le Deploy CLI d’Auth0.

Le Deploy CLI prend en charge le travail dans un contexte multi-locataire et multi-environnement. Intégré à vos flux de travail de développement CI/CD, il peut servir à propager les changements 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 tenant Auth0 distinct pour chaque environnement (développement, préproduction, production).
2. Créez un seul dépôt 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 de ressources Auth0 au tenant Auth0 approprié.

​

Correspondance tenant-environnement

Il est recommandé d’avoir un tenant/compte Auth0 distinct pour chaque environnement. Par exemple :

Environnement	Tenant
Développement	travel0-dev
Tests	travel0-uat
Préproduction	travel0-stage
Production	travel0-prod

​

Dépôt de configuration des ressources

Une fois exporté, l’état de votre tenant Auth0 sera représenté par un ensemble de fichiers de configuration des ressources, dans un format YAML ou répertoire. Dans un contexte multi-environnement, on s’attend à utiliser un seul dépôt de configurations de ressources pour tous les environnements. En pratique, ce dépôt peut se trouver dans un répertoire du code source de votre projet ou dans un code source distinct.

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

Votre flux de travail pourrait ressembler à ceci :

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

Par précaution, vous pourriez configurer votre environnement de production pour qu’il se déploie uniquement lors d’un déclenchement manuel.

​

Flux unidirectionnel

Le flux de travail multi-environnement 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’en production. Cette approche unidirectionnelle garantit des tests et des approbations suffisants pour les changements apportés à votre tenant. Une fois cette approche établie, il est recommandé de ne pas appliquer directement de configurations en production par d’autres moyens, comme le Auth0 Dashboard ou la Management API, à moins que ces changements ne soient consignés dans une exportation subséquente du Deploy CLI. Sinon, ces changements risquent d’être écrasés.

​

Valeurs propres à l’environnement

Bien qu’il soit prévu que tous les environnements partagent le même ensemble de fichiers de configuration des ressources, les valeurs propres à l’environnement peuvent être définies au moyen de fichiers de configuration distincts pour l’outil et du remplacement dynamique de mots-clés.

​

Fichiers de configuration distincts

Le fait de définir un fichier de configuration de l’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 informations d’authentification distinctes pour chaque environnement, mais il est aussi possible d’exclure certaines ressources, d’activer la suppression et d’effectuer un remplacement dynamique de mots-clés selon l’environnement.

​

Exemple d’arborescence de fichiers

project-root
│
└───auth0
│   │   config-dev.json   # Fichier de configuration de l'environnement de développement
│   │   config-test.json  # Fichier de configuration de l'environnement de test
│   │   config-prod.json  # Fichier de configuration de l'environnement de production
│   │   ... tous les autres fichiers de configuration des ressources
│
└───src
    │   ... le code de votre projet

​

Valeurs dynamiques avec remplacement de mots-clés

Une fois que des fichiers de configuration distincts sont utilisés pour chaque environnement, vous pouvez utiliser le remplacement de mots-clés au moyen de la propriété de configuration AUTH0_KEYWORD_REPLACE_MAPPINGS pour définir des valeurs de remplacement dynamiques selon l’environnement. Par exemple, vous pourriez devoir utiliser un ensemble distinct d’origines autorisées pour vos applications clientes. Pour en savoir plus, consultez Keyword Replacement.

​

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