Passer au contenu principal
Lorsque vous travaillez dans un environnement Enterprise Knowledge (EK) Cloud à tenant unique, il n’est pas possible d’avoir des tenants de développement et de production séparés par défaut. Cet article décrit l’approche recommandée pour gérer votre cycle de vie de développement et promouvoir les solutions du développement vers la production au sein du même tenant.

​
Approche recommandée : utiliser des projets séparés pour Dev et Prod

La recommandation principale est de traiter les Projets dans EK comme limite de votre environnement. Plutôt que de construire directement dans un projet de production, vous devez maintenir un projet de développement dédié où toute la configuration, les tests et l’itération s’effectuent avant toute promotion de solution vers la production.

​
Phase de développement

Tout le développement de solution doit se dérouler dans un projet dev désigné. Cela inclut la configuration des sources de connaissances, la création et les tests d’agents, la configuration des outils et intégrations, et la définition des workflows. Garder ce travail isolé dans un projet dev garantit que votre environnement de production reste stable et sans affectation lors du développement actif. Une fois le développement terminé, la solution doit passer par les tests d’acceptation utilisateur (UAT) au sein de ce même projet dev. Les parties prenantes et les utilisateurs finaux peuvent valider le comportement, tester les cas limites et approuver la solution avant toute promotion. Ce n’est qu’après l’approbation de l’UAT que vous devriez procéder à la création du projet de production.

​
Promotion vers la production

EK Cloud offre deux méthodes pour promouvoir un projet dev vers la production au sein du même tenant : Option 1 – Exporter et importer Exportez le projet dev depuis EK et importez-le en tant que nouveau projet au sein du même tenant. Cela vous donne un projet de production propre qui reflète la configuration dev au moment de l’export. Option 2 – Cloner et renommer Clonez le projet dev directement au sein du tenant, puis renommez le projet cloné pour refléter son objectif de production. Les deux projets coexisteront au sein du même tenant, et le projet dev est préservé dans son état actuel. L’une ou l’autre méthode aboutit à un nouveau projet indépendant qui sert d’environnement de production.

​
Étapes post-migration

Indépendamment de la méthode que vous utilisez, plusieurs éléments requièrent une attention manuelle après la création du projet de production. Ils ne sont pas transférés automatiquement et doivent être reconfigurés avant que la solution soit en production.

​
Membres du projet

Les membres du projet ne sont pas transférés lors d’une opération d’export/import ou de clonage. Tous les utilisateurs qui ont besoin d’accès au projet de production doivent être ajoutés manuellement.

​
Authentification des services tiers

Toute intégration connectée à des services externes — tels que les fournisseurs de stockage cloud, les CRM ou d’autres plateformes SaaS — doit être réauthentifiée dans le nouveau projet de production. Les identifiants et les connexions OAuth sont limités au projet dans lequel ils ont été initialement configurés et ne sont pas transférés lors de l’export/import ou du clonage.

​
Clés API pour les outils

Si des outils au sein de la solution s’appuient sur des clés API, ces clés doivent être réémises et reconnectées au sein du projet de production. Ne réutilisez pas les clés API dev en production, tant pour des raisons de sécurité que parce que les clés dev peuvent avoir des limites de taux différentes ou des étendues d’accès différentes.

​
Connexions Automation Anywhere APA Control Room

Si la solution est connectée à une instance Automation Anywhere APA Control Room, cette connexion doit être rétablie dans le projet de production en pointant vers l’APA Control Room de production. Les environnements APA dev et production sont distincts, et la connexion configurée dans le projet dev fera référence à l’instance APA dev. Ne pas mettre à jour cette connexion signifie que votre solution EK de production continuera à déclencher ou communiquer avec l’environnement APA de développement.

​
Résumé

​
Notes

  • Il n’y a pas de synchronisation automatisée entre les projets dev et prod. Toute modification apportée post-UAT dans le projet dev doit être manuellement re-promue.
  • Il est recommandé de maintenir le projet dev après le lancement pour soutenir les itérations et les tests futurs.
  • Les conventions de nommage des projets doivent clairement distinguer dev de prod pour éviter une configuration accidentelle dans le mauvais environnement (par exemple, MonProjet_DEV et MonProjet_PROD).