Passer au contenu principal
En plus d’adopter les meilleures pratiques pour la gestion du changement et l’QA (AQ), les clients qui réussissent intégreront également la gestion des garanties Auth0 dans le cadre de certains processus de déploiement automatisé. Comme indiqué dans la section Architecture sous SDLC support (Support SDLC), vous vous assurerez de configurer des locataires Auth0 distincts pour les environnements de développement, de test et de production, et vous voulez que cette configuration soit presque identique pour le locataire dans chaque environnement. L’utilisation de l’automatisation du déploiement contribue à garantir cela, afin que chaque locataire d’environnement soit configuré de la même manière, et il sera moins probable que des bogues apparaissent en raison de configurations incompatibles entre les environnements.

​
Meilleures pratiques

Quelle que soit la configuration de l’automatisation du déploiement, nous vous recommandons de tester vos règles, vos scripts de base de données personnalisés et vos hooks avant le déploiement, et d’exécuter des tests d’intégration avec votre locataire après le déploiement. Pour plus de détails à ce sujet, voir le guide Assurance qualité. Auth0 offre une prise en charge pour plusieurs options différentes concernant les approches d’automatisation du déploiement que vous pouvez utiliser, et chacune peut être utilisée en conjonction avec l’autre si souhaité :
  • L’outil Auth0 Deploy CLI vous offre un script facile d’utilisation pouvant vous aider à intégrer dans votre pipeline existant d’Intégration continue/déploiement continu (CI/CD).
  • Si vous ne pouvez pas intégrer directement avec, ou pour une raison quelconque, vous n’avez pas de pipeline CI/CD, alors les Extensions de contrôle de source Auth0 peuvent fournir un processus d’automatisation de base facile à configurer avec très peu de maintenance.
Notez que l’outil Deploy CLI et les extensions de contrôle de source peuvent provoquer des changements destructeurs. Les modifications manuelles effectuées directement dans le tableau de bord entre les déploiements automatisés peuvent être perdues! Pour cette raison, si l’un des deux est utilisé,  toutes les modifications doivent alors être déployées à partir du sous-système de contrôle de la source référencé par le biais de l’outil et non pas effectuées manuellement.
Chaque environnement peut avoir besoin de configuration qui lui soit spécifique - l’ID client de l’application et les Secrets client diffèrent entre les clients Auth0, par exemple. Ainsi, vous chercherez une façon de référencer dynamiquement plutôt que d’avoir des valeurs codées de manière rigide. Auth0 vous fournit du soutien pour gérer une information de configuration spécifique à l’environnement selon une de deux approches :

​
Variables spécifiques au locataire

Auth0 vous permet de configurer des variables qui sont disponibles dans extensibility (extensibilité) personnalisée; celles-ci peuvent être considérées comme des variables d’environnement pour votre locataire Auth0. Plutôt que des références en code fixe qui changent lorsque le code est déplacé entre les développements, les tests, et les environnements de production, vous pouvez utiliser un nom variable configuré dans le client et référencé par le code d’extensibilité personnalisée. Cela facilite l’utilisation du même code personnalisé, sans modifications, dans différents locataires, car le code peut faire référence à des variables qui seront remplies avec des valeurs spécifiques au locataire au moment de l’exécution.

​
Meilleure pratique

Il est conseillé d’utiliser des variables pour contenir des valeurs spécifiques au locataire ainsi que des secrets sensibles qui ne devraient pas être exposés dans votre code personnalisé. Si votre code personnalisé est déployé dans GitHub/Gitlab/Bitbucket/VSTS, l’utilisation d’une variable spécifique au locataire permet d’éviter l’exposition de valeurs sensibles via votre dépôt.

​
Guide de planification de projet

Nous fournissons un guide de planification en format PDF que vous pouvez télécharger; vous pouvez vous y référer pour de plus amples détails concernant nos stratégies recommandées. B2B IAM Project Planning Guide

​
Architecture pour organisations multiples (Multilocataire)

Plusieurs plateformes mettent en œuvre une forme d’isolation et/ou d’image de marque pour les organisations de leurs clients, ce qui peut ajouter de la complexité à tout système de Gestion des identités et des accès (IAM). Si cela s’applique à vous, nous vous conseillons de prendre le temps de lire nos conseils et bonnes pratiques pour ce type d’environnement. Architecture à organisations multiples
⌘I