Skip to main content
En plus d’adopter des pratiques exemplaires de gestion des changements et d’AQ, les clients qui réussissent intègrent aussi la gestion des ressources Auth0 à un processus de déploiement automatisé. Comme il est indiqué dans la section Architecture sous SDLC support, vous voudrez vous assurer de configurer des tenants Auth0 distincts pour les environnements de développement, de test et de production, et que cette configuration soit presque identique d’un environnement à l’autre. L’automatisation du déploiement permet de s’en assurer, de sorte que le tenant de chaque environnement soit configuré de la même façon et que les bogues causés par des écarts de configuration entre les environnements soient moins susceptibles de se produire.

Pratique exemplaire

Peu importe la façon dont vous configurez l’automatisation du déploiement, nous vous recommandons d’effectuer des tests unitaires de vos Rules, custom DB scripts et hooks avant le déploiement, puis d’exécuter également des tests d’intégration sur votre tenant après le déploiement. Pour en savoir plus à ce sujet, consultez les recommandations d’Assurance qualité.
Auth0 offre quelques options différentes pour l’automatisation du déploiement, et vous pouvez les utiliser ensemble au besoin :
  • L’outil Auth0 Deploy CLI vous fournit un script facile à utiliser qui peut vous aider à l’intégrer à votre pipeline d’intégration continue et de déploiement continu (CI/CD).
  • Si vous ne pouvez pas intégrer directement un pipeline CI/CD, ou si pour une raison quelconque vous n’en avez pas, les Source Control Extensions d’Auth0 peuvent offrir un processus d’automatisation de base facile à configurer et nécessitant très peu de maintenance.
Notez que l’outil Deploy CLI et les source control extensions peuvent tous deux entraîner des changements destructifs ; les modifications manuelles apportées directement dans le Dashboard entre des déploiements automatisés pourraient être perdues ! Pour cette raison, si l’un ou l’autre est utilisé, toutes les modifications doivent être déployées à partir du sous-système de contrôle de code source référencé par l’outillage, et non effectuées manuellement.
Chaque environnement peut aussi nécessiter une configuration propre à l’environnement — les d’Application et les seront différents d’un tenant Auth0 à l’autre, par exemple — vous voudrez donc pouvoir y faire référence de façon dynamique plutôt que d’utiliser des valeurs codées en dur. Auth0 prend en charge la gestion des informations de configuration propres à l’environnement au moyen de l’une des deux approches suivantes :

Variables propres au tenant

Auth0 vous permet de configurer des variables accessibles depuis votre extensibilité personnalisée; elles peuvent être considérées comme des variables d’environnement pour votre tenant Auth0. Au lieu d’intégrer en dur des références qui changent lorsque vous déplacez du code entre les environnements de développement, de test et de production, vous pouvez utiliser un nom de variable configuré dans le tenant et référencé par le code d’extensibilité personnalisée. Il est ainsi plus facile d’utiliser le même code personnalisé, sans modification, dans différents tenants, puisque le code peut référencer des variables qui seront renseignées avec des valeurs propres au tenant au moment de l’exécution :

Pratique exemplaire

Il est recommandé d’utiliser des variables pour stocker des valeurs propres au tenant ainsi que tout secret sensible qui ne devrait pas être exposé dans votre code personnalisé. Si votre code personnalisé est déployé dans GitHub/GitLab/Bitbucket/VSTS, l’utilisation d’une variable propre au tenant permet d’éviter l’exposition de valeurs sensibles dans votre dépôt.

Guide de planification de projet

Nous fournissons un guide de planification en format PDF que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons. Guide de planification de projet B2B IAM

Multiple Organization Architecture (Multitenancy)

De nombreuses plateformes B2B offrent une certaine forme d’isolation et/ou d’image de marque pour l’organisation de leurs clients, ce qui peut ajouter de la complexité à tout système de gestion des identités et des accès (IAM). Si c’est votre cas, nous vous recommandons de prendre le temps de consulter nos recommandations et nos conseils de bonnes pratiques pour ce type d’environnement. Multiple Organization Architecture