Passer au contenu principal
Outre l’adoption de pratiques exemplaires en matière de gestion du changement et d’assurance qualité, les clients intégreront également la gestion des garanties Auth0 dans le cadre d’un processus de déploiement automatisé. Comme expliqué dans la section Architecture sous Soutien SDLC, vous devrez vous assurer de configurer les locataires Auth0 séparément pour les environnements de développement, de test et de production, et cette configuration doit être presque identique pour le locataire de 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.

​
Meilleure pratique

Quelle que soit la configuration de l’automatisation du déploiement, nous vous conseillons de tester vos règles, vos scripts de base de données personnalisés et vos hooks avant le déploiement, et de réaliser également des tests d’intégration sur votre locataire après le déploiement. Pour plus de détails à ce sujet, voir le guide Assurance qualité fourni. 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 permettant une intégration dans votre pipeline Intégration continue/déploiement continu existant (CI/CD).
  • Si vous ne pouvez pas effectuer une intégration directe avec un pipeline CI/CD ou si, pour une raison quelconque, vous ne disposez pas d’un tel pipeline, les extensions de contrôle de source d’Auth0 peuvent offrir un processus d’automatisation de base facile à mettre en place et nécessitant 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, accessibles dans les options d’extensibilité personnalisées; ces variables 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. Ceci vous rend la tâche plus facile pour faire foncitionner le même code personnalisé, sans changements, pour différents clients; le code peut référencier les variables, lesquelles seront présentes avec des valeurs spécifiques aux clients pour des temps d’exécution :
  • Pour utiliser des variables dans les actions, consultez Créer votre première action pour découvrir comment configurer des secrets dans l’éditeur.
  • Pour utiliser des variables dans les règles, apprenez à configurer les valeurs
  • Pour utiliser des variables dans les hooks, apprenez à configurer des secrets dans l’éditeur.
  • Pour utiliser des variables dans les scripts de base de données personnalisés, vérifiez les paramètres de configuration

​
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. B2C IAM Project Planning Guide
⌘I