Développement de scriptsCycle de vie Gestion
À moins d'indication contraire, les renseignements de cette page d'aide ne s'appliquent qu'à Studio. Pour protéger la sécurité des scripts dans les différentes étapes, les dossiers affectés aux étapes du flux de travail de développement ne sont pas visibles dans Desktop Studio.
Studio fournit un système d'étapes de développement pour vous aider à gérer le cycle de vie du développement de scripts de votre entreprise. Les étapes de développement sont un outil pour organiser vos scénarios et gérer leur promotion tout au long de leur cycle de vie.
Les étapes de développement organisent les scripts en fonction de leur position dans le processus de développement. Vous pouvez configurer jusqu'à quatre étapes pour correspondre au processus suivi par vos développeurs de scripts. Par exemple, vous pourriez utiliser des étapes pour le développement, les tests et la production. Lorsqu'un développeur de scripts crée ou modifie un script, il travaille dans la phase de développement. Ensuite, lorsqu'un script est prêt à être testé, ils peuvent le faire passer à l'étape suivante.
Dans le domaine de l’ingénierie logicielle, de nombreuses organisations suivent des méthodologies qui utilisent une approche en plusieurs étapes pour le développement. Dans ces méthodologies, le cycle de développement des logiciels (SDLC) consiste en des étapes de planification, de conception, de développement, de test et de déploiement des changements logiciels. Le respect d’une méthodologie SDLC en plusieurs étapes permet d’améliorer la qualité du produit final et de rationaliser le processus de développement.
Structure de votre processus de développement
Studio prend en charge votre flux de travail de développement au sein de la structure de dossiers de script. La manière exacte dont cela est géré dépend de si votre CXone Mpower système est configuré pour divisions
Séparez les données en toute sécurité entre les différents secteurs d’activité. Les données ne peuvent être consultées qu’au sein de la division dont elles font partie.. Si votre système utilise divisions, l'organisation des scripts s'aligne sur vos divisions. Si votre système n'utilise pas de divisions, Studio vous permet d'organiser les scripts à l'aide de organisations.
Les organisations et les divisions sont toutes deux affectées à des dossiers dans Studio. Les dossiers sont situés dans le stockage de fichiers ACD dans CXone Mpower. Chaque organisation ou division possède son propre ensemble de dossiers, composé d'un dossier principal et d'un dossier pour chaque étape de développement utilisée dans cette organisation ou division. Dans chaque dossier d'étape, vous créez des sous-dossiers pour organiser les scripts. Le seul sous-dossier requis se trouve dans l'étape de développement de niveau le plus bas, qui doit contenir un dossier appelé main.
Les développeurs de scripts font passer les scripts d'une étape à l'autre. Ils pourront choisir le dossier de destination à l'étape suivante. Vous pouvez configurer la sécurité des scripts selon les besoins de chaque organisation ou division. Les permissionsStudio offrent un niveau de contrôle granulaire sur qui peut accéder et interagir avec les scripts de votre entreprise étape par étape. Pour les divisions, les autorisations de flux de travail de développement vous permettent un contrôle plus précis au sein de chaque division afin de contrôler l'accès aux scripts.
Flux de travail de développement avec les organisations
Studio vous oblige à créer une organisation lors de la configuration de votre flux de travail de développement. Les organisations ne sont une entité que dans Studio. Leur seul but est d'organiser les étapes de développement et les scripts qu'elles contiennent.
Une organisation définit un ensemble d'étapes de développement et les dossiers qui leur sont associés. Si vous utilisez un système de contrôle de version tiers avec Studio, l'organisation définit également le référentiel dans lequel les scripts sont validés. Chaque organisation peut utiliser un dépôt différent.
Vous pouvez créer plusieurs organisations. Les organisations peuvent correspondre à différentes équipes, différents secteurs d’activité ou d’autres groupes au sein de votre entreprise. Si votre centre de contact est petit ou si votre entreprise a une structure simple et directe, une seule organisation peut suffire. Toutefois, vous pourriez vouloir démarrer plusieurs organisations si votre entreprise :
- souhaite utiliser plusieurs référentiels pour ses scripts;
- Utilise différentes étapes de développement dans différents groupes ou équipes.
- Souhaite que les scripts provenant de différents groupes, équipes ou secteurs d'activité restent séparés les uns des autres.
Chaque organisation a son propre dossier dans votre CXone Mpower système. Tous les scripts de chaque organisation sont stockés dans ce dossier.
Si votre entreprise n'a pas besoin de plusieurs organisations, vous n'avez pas besoin de créer un dossier pour les scripts de l'organisation. Cela signifie que les dossiers de vos étapes de développement peuvent être situés à la racine de votre structure de fichiers Studio.
Flux de travail de développement avec divisions
Les divisions permettent aux organisations de segmenter en toute sécurité les données au sein de leurs CXone Mpower système pour séparer les différentes lignes d'activité. Il s'agit d'une entité qui existe au sein de CXone Mpower. Lorsque activées, les divisions affectent toutes les données plateforme, y compris les scripts Studio.
Un administrateur CXone Mpower doit créer des divisions dans le Admin application. Après cela, vous pouvez associer les divisions aux dossiers dans Studio. La structure des dossiers à l'intérieur de Studio doit correspondre à la structure hiérarchique des divisions à l'intérieur de CXone Mpower système. Votre administrateur plateforme responsable des divisions peut vous aider à déterminer la hiérarchie.
Chaque division a son propre ensemble d'étapes de développement. Si vous utilisez un système de contrôle de version tiers avec Studio, le dépôt est attribué par division. Chaque division peut utiliser un référentiel différent.
Comparaison des organisations et des divisions
Le tableau suivant résume les différences entre les organisations et les divisions et leur prise en charge des fonctionnalités du flux de travail de développement.
| Entreprise | Division | |
|---|---|---|
| Entité dans CXone Mpower | Non | Oui |
|
Exigences relatives aux dossiers de niveau supérieur dans Studio |
Chaque organisation doit avoir son propre dossier de niveau supérieur attribué dans Studio. Une organisation n'a pas besoin d'un dossier racine. Vous pouvez utiliser le répertoire racine pour stocker les dossiers de l'étape de développement. |
Chaque division doit avoir son propre dossier. La structure des dossiers doit correspondre à la structure de division dans le plateforme. |
| Appuie les étapes de développement |
Oui Chaque organisation possède un ensemble unique d'étapes et de dossiers d'étapes. |
Oui Chaque division possède un ensemble unique d'étapes et de dossiers d'étapes. |
| Prend en charge l'intégration de systèmes de contrôle de version tiers |
Oui Chaque organisation peut utiliser son propre référentiel. |
Oui Chaque division peut utiliser son propre référentiel. |
| Prend en charge les permissions pour contrôler l'accès des utilisateurs aux scripts et aux étapes. | Oui | Oui |
Étapes du développement
Les étapes de développement sont au cœur de la gestion du cycle de vie du développement de votre script. Vous pouvez définir jusqu'à quatre étapes pour correspondre aux processus établis de votre entreprise. Par exemple, si le cycle de vie de développement de votre entreprise comporte deux étapes, dev et prod, vous pouvez configurer vos étapes de développement dans Studio pour qu'elles correspondent. Vous pouvez personnaliser les noms de vos étapes de développement pour qu'ils correspondent aux noms auxquels vos développeurs de scripts sont habitués.
Les étapes de développement sont des enfants d'une organisation ou d'une division, selon la façon dont votre CXone Mpower système est configurée. Chaque organisation ou division possède son propre ensemble unique d'étapes de développement. Cela vous permet de personnaliser les flux de travail de développement pour chaque organisation ou division.
Dans un premier temps, il doit y avoir un dossier appelé main. Cela représente la branche principale des systèmes de contrôle de version, comme GitHub. Tous les scripts doivent être situés dans le dossier main . Les développeurs de scripts peuvent créer des sous-dossiers dans main pour organiser les scripts. Le dossier main est requis si vous souhaitez utiliser un système de contrôle de version tiers avec Studio. Même si vous ne prévoyez pas d'utiliser le contrôle de version, vous devez stocker tous les scripts de votre étape de niveau le plus bas dans un main folder.
Les autres étapes n'ont pas les mêmes exigences en matière de dénomination des dossiers. Vous pouvez avoir autant de sous-dossiers que vous le voulez dans les trois autres étapes, et vous pouvez leur donner n'importe quel nom. Cela vous permet d'utiliser des sous-dossiers pour organiser les scripts de manière à répondre aux besoins de votre entreprise, par exemple par version.
Christopher Robin, l'administrateur Studio de Classics, Inc. met en place des étapes de développement. Classics, Inc. possède deux lignes de métier (LOB), Classic Texts, qui vend et loue des manuels scolaires aux étudiants universitaires, et Classic Cafe and Books, une chaîne de cafés-librairies.
Il commence par créer et s'attribuer un rôle dans CXone Mpower Admin qui a la permission de créer, de modifier et de promouvoir aux quatre étapes.
Christopher consulte les gestionnaires des équipes de script du studio pour chaque secteur d'activité et se renseigne sur le cycle de développement de chaque équipe. Ensuite, il crée deux organisations, ClassicTexts et ClassicCafe, chacune avec ses étapes de développement appropriées sur la page Développement du flux de travail dans Studio.
Ensuite, Christopher crée la structure de dossiers dans Studio. Il crée un script temporaire pour chaque organisation LOB et choisit l'option permettant de saisir le chemin du dossier, en le nommant \dev\main pour les deux organisations.
Finalement, Christopher déploie le scénario temporaire à travers chacune des étapes qu'il a créées dans chaque organisation. Il ne crée aucun sous-dossier dans les niveaux supérieurs. Au lieu de cela, il se contente de transférer le script dans le dossier de la scène. Pour terminer, il désactive le script temporaire.
Christopher peut maintenant voir la structure de dossiers suivante dans Studio :
Café classique
\Dev
\principal
\Prod
\Texte classique
\Dev
\principal
QA
\Prod
Promotion et copie du script
Lorsqu'un script est prêt à passer à l'étape suivante, un développeur de scripts disposant des autorisations appropriées peut le promouvoir. Les Scripts ne peuvent être promus qu'à l'étape immédiatement supérieure. Ils ne peuvent également être promus qu'à des niveaux configurés pour l'organisation ou la division à laquelle appartient le développeur du script.
La promotion d'un script crée une copie de ce script dans l'environnement de destination. Il copie également tous les dossiers présents dans le chemin d'accès à l'emplacement du script, à l'exception du dossier de stage. Cela renforce la structure organisationnelle créée par vos développeurs de scripts.
Tigger Tiggerson est un développeur de scripts chez Classic Texts. Il travaille sur le script A, qui se trouve dans /QA/Jan2025/TiggerTest/IBVoice. Il le fait passer à l'étape de production. Lorsqu'il consulte le dossier Prod, il constate que le chemin complet /Jan2025/TiggerTest/IBVoice a été copié avec le fichier ScriptA. Le dossier /QA n'a pas été copié parce qu'il s'agit du dossier de préparation.
Par défaut, lors de la promotion des scripts, ceux-ci sont stockés dans les mêmes sous-dossiers que dans l'environnement de développement de destination. Les développeurs de scripts peuvent modifier le sous-dossier dans lequel le script est stocké, y compris créer un nouveau dossier.
Votre entreprise peut élaborer des processus internes pour définir les conditions de passage d'un scénario à l'autre. Studio ne respecte pas ces conditions ni ne vérifie qu'elles ont été remplies. Toutefois, vous pouvez utiliser les rôles et les permissions CXone Mpower pour contrôler quels utilisateurs Studio peuvent être promus à chaque étape. Vous pouvez également contrôler qui peut consulter, créer et modifier des scripts à chaque étape.
Modifications apportées aux Scripts promus
Le respect d'un flux de travail typique de cycle de vie de développement de scripts implique que, lorsque des modifications sont nécessaires à un script se trouvant à un stade supérieur, les développeurs de scripts doivent travailler sur la copie du script se trouvant à l'étape désignée pour le développement. Toutefois, si les scripts ont été modifiés à un niveau supérieur, ils peuvent être dupliqués dans le dossier de niveau le plus bas. Cela ne devrait être nécessaire que si une correction d'urgence était requise et était apportée directement au script à un niveau supérieur.
Lorsqu'un script est promu ou dupliqué vers une autre étape de développement, il est copié dans le dossier de l'étape de destination. Si le script se trouve dans un sous-dossier du dossier d'une étape, le sous-dossier et le chemin d'accès à celui-ci sont copiés dans le dossier de l'étape de destination.
Des Autorisations sont requises pour promouvoir et dupliquer des scripts vers d'autres étapes de développement. Les développeurs de scripts doivent posséder :
- La permission de promouvoir les scénarios pour la scène à laquelle ils les promeuvent.
- L'autorisation Créer/Modifier pour l'étape vers laquelle ils dupliquent les scripts.
- Autorisation d'affichage pour l'étape dans laquelle se trouve actuellement le script.
La promotion ou la duplication d'un script vers une étape de développement différente écrase l'ancienne version du script si elle existe à l'étape de destination. Si nécessaire, les développeurs de scripts peuvent comparer les scripts pour déterminer les différences avant de les promouvoir ou de les dupliquer. Ils peuvent aussi consulter l'historique des versions d'un script et revenir à une version antérieure, si des modifications ont été écrasées.
Contrôle d'accès aux scripts et aux données
Vous pouvez contrôler qui peut accéder aux scripts à chaque étape de développement que vous définissez dans Studio. En utilisant les permissions attribuées aux rôles dans Admin, vous pouvez restreindre la capacité des développeurs de scripts à consulter, créer et modifier, et désactiver les scripts à chaque étape. Vous pouvez également contrôler les étapes vers lesquelles les développeurs peuvent promouvoir les scripts.
Ces autorisations s'appliquent aux organisations et divisions:
-
Pour les organisations, ces autorisations n'empêchent pas les développeurs de scripts de pouvoir consulter les scripts d'autres organisations. Si le développeur est autorisé à consulter les scripts en phase de développement, il pourra voir tous les scripts du dossier de développement dans chaque organisation.
-
Avec divisions
Séparez les données en toute sécurité entre les différents secteurs d’activité. Les données ne peuvent être consultées qu’au sein de la division dont elles font partie., les développeurs de scripts ne peuvent voir que les scripts de la division à laquelle ils sont affectés ou de toutes les divisions enfants de la division à laquelle ils sont affectés. Par exemple, les développeurs de scripts autorisés à consulter les scripts en phase de développement dans leur division respective ne pourront pas voir les dossiers en phase de développement d'autres divisions du même niveau hiérarchique ou d'un niveau supérieur.
Gestion des scripts par étapes
Une fois vos étapes de développement configurées, les développeurs de scripts peuvent commencer à travailler dans le système. Vous devez vous assurer que vos développeurs comprennent comment travailler au sein du système que vous avez mis en place.
Lors de la conception de vos processus, tenez compte des éléments suivants :
- Quelles étapes avez-vous mises en place dans Studio.
- Les critères pour déterminer quand et comment un scénario peut être promu à chaque étape du développement.
- Qui peut promouvoir des scénarios et jusqu'à quel stade ?
- Que faire si un script de niveau supérieur doit être modifié ? Par exemple, ils devraient travailler sur la copie de ce script pendant la phase de développement et la faire remonter graduellement à travers les différentes phases.
- Que faire si une modification corrective a été apportée à un script à un stade supérieur ? Par exemple, faut-il copier cette version du script dans l'environnement de développement ? Les développeurs de scripts peuvent comparer les scripts pour voir quelle est la version la plus récente.
- Toute autre directive ou garde-fou que votre entreprise a mis en place pour le développement de scripts.
Contrôle des versions des scripts
Le contrôle des versions vous permet de suivre et de gérer les modifications apportées à vos scripts au cours de leur développement. Cela vous permet de rechercher les problèmes lorsqu’ils se présentent. Si nécessaire, vous pouvez revenir à une version antérieure d’un script afin d’annuler une modification problématique.
Studio propose deux options pour le contrôle des versions des scripts :
- Historique des scripts : Studio conserve un nombre configurable de versions antérieures de chaque script. Chaque fois que le script est enregistré, il crée un enregistrement de cette version historique. Vous pouvez consulter les versions précédentes et revenir à celles-ci si nécessaire. Cette option est prise en charge dans Desktop Studio et Studio.
- Systèmes de contrôle de Version tiers : Studio peut enregistrer les modifications de script dans un système de contrôle de Version tiers. Actuellement, GitHub est le seul fournisseur pris en charge. Cette fonctionnalité fait partie d’un programme de version contrôlée. Contactez votre Représentant de compte si vous souhaitez en savoir plus.
Les deux options de contrôle des versions des scripts fonctionnent en parallèle. Si vous utilisez un système de contrôle des versions, vous pouvez toujours consulter les versions antérieures d’un script conservé par Studio et y revenir. Cependant, GitHub ne le considère pas comme une réversion. Il considère par contre le script rétabli comme de nouvelles modifications.
De même, si vous utilisez les étapes de développement dans Studio, vous pouvez consulter les versions précédentes d'un script. Cependant, les versions antérieures sont limitées aux versions de chaque étape. Pour consulter les versions antérieures à partir d’une autre étape, vous devez consulter le script depuis cette étape. L’affichage des scripts à différentes étapes nécessite que vous disposiez des autorisations nécessaires pour travailler sur cette étape.
Faits clés sur les étapes de développement dansStudio
- Si votre entreprise utilise des divisions , vous pouvez avoir des étapes de développement distinctes au sein de chaque division. Studio Les utilisateurs ne peuvent accéder qu'aux scripts de leur division qui se trouvent dans des dossiers qu'ils sont autorisés à consulter.
- Si vous n'utilisez pas de divisions, les utilisateurs Studio ne peuvent accéder qu'aux scripts situés dans des étapes de développement qu'ils sont autorisés à consulter.
- Vous pouvez configurer jusqu'à quatre étapes de développement et personnaliser les noms pour qu'ils correspondent à la terminologie de votre entreprise. Les noms figurant sur la page des permissions dans Admin sont fixes. Cependant, dans Studio, vous pouvez définir vos propres noms. Les noms que vous attribuez à chaque étape dans Studio sont ceux qui apparaissent pour les développeurs de scripts utilisant Studio.
-
À chaque étape, les développeurs de scripts peuvent créer des sous-dossiers pour organiser leurs scripts.
- Vous pouvez configurer une intégration avec un système de contrôle de version tiers. Cela permet aux développeurs de scripts de pousser leurs scripts vers le dépôt désigné. Actuellement, GitHub est le fournisseur pris en charge.