Gestión del ciclo de vida de Script Development

A menos que se indique lo contrario, la información de esta página de ayuda solo se aplica a Studio. Para proteger la seguridad de los scripts en las diversas etapas, las carpetas asignadas a las etapas del flujo de trabajo de desarrollo no están visibles en Desktop Studio.

Studio proporciona un sistema de etapas de desarrollo para ayudarle a gestionar el ciclo de vida del desarrollo de scripts de su empresa. Las etapas de desarrollo son una herramienta para organizar sus scripts y administrar la promoción de scripts a través del ciclo de vida del desarrollo de scripts.

Las etapas de desarrollo organizan los scripts en función de dónde se encuentran en el proceso de desarrollo. Puede configurar hasta cuatro etapas para que coincidan con el proceso que siguen los desarrolladores de sus scripts. Por ejemplo, podría utilizar etapas para desarrollo, pruebas y producción. Cuando un desarrollador de scripts crea o edita un script, trabaja en la etapa de desarrollo. Luego, cuando un guión está listo para ser probado, pueden promoverlo a la siguiente etapa.

Estructura de su flujo de trabajo de desarrollo

Studio respalda su flujo de trabajo de desarrollo dentro de la estructura de carpetas de script. La forma exacta en que se gestiona esto depende de si su CXone Mpower sistema está configurado para divisiones Separe los datos de forma segura entre las distintas líneas de negocio. Solo se puede acceder a los datos desde la división a la que pertenecen.. Si su sistema utiliza divisiones, la organización de los scripts se alinea con sus divisiones. Si su sistema no utiliza divisiones, Studio le permite organizar scripts usando organizaciones.

Tanto las organizaciones como las divisiones se asignan a carpetas dentro de Studio. Las carpetas se encuentran en el almacenamiento de archivos ACD en CXone Mpower. Cada organización o división tiene su propio conjunto de carpetas, que consta de una carpeta de nivel superior y una carpeta para cada etapa de desarrollo utilizada en esa organización o división. Dentro de cada carpeta de etapa, crea subcarpetas para organizar los scripts. La única subcarpeta requerida está en la etapa de desarrollo de nivel más bajo, que debe tener una carpeta llamada main.

Los desarrolladores de scripts promueven scripts de una etapa a la siguiente. Podrán elegir la carpeta de destino en la siguiente etapa. Puede configurar la seguridad del script según sea necesario para cada organización o división. Studio Los permisos proporcionan un nivel granular de control sobre quién puede acceder e interactuar con los scripts de su empresa etapa por etapa. Para las divisiones, los permisos del flujo de trabajo de desarrollo permiten un control más preciso dentro de cada división para controlar el acceso a los scripts.

Flujo de trabajo de desarrollo con organizaciones

Studio requiere que cree una organización al configurar su flujo de trabajo de desarrollo. Las organizaciones son una entidad sólo dentro de Studio. Su único propósito es organizar las etapas de desarrollo y los scripts que contienen.

Una organización define un conjunto de etapas de desarrollo y las carpetas asociadas a ellas. Si utiliza un sistema de control de versiones de terceros con Studio, la organización también define el repositorio al que se confirman los scripts. Cada organización puede utilizar un repositorio diferente.

Puedes crear más de una organización. Las organizaciones pueden relacionarse con distintos equipos, líneas de actividad u otras delineaciones de su empresa. Si su centro de contacto es pequeño o su empresa tiene una estructura sencilla y directa, una sola organización puede ser todo lo que necesita. Sin embargo, es posible que desee crear más de una organización si su empresa:

Desea usar más de un repositorio para sus scripts.
Utiliza diferentes etapas de desarrollo en diferentes grupos o equipos.
Quiere mantener los scripts de diferentes grupos, equipos o líneas de negocio separados unos de otros.

Cada organización cuenta con su propia carpeta en su CXone Mpower sistema. Todos los scripts de cada organización se almacenan en esa carpeta.

Si su empresa no necesita varias organizaciones, no necesita crear una carpeta para los scripts de la organización. Esto significa que las carpetas para las etapas de desarrollo se pueden ubicar bajo la raíz de la estructura de archivos Studio.

Flujo de trabajo de desarrollo con divisiones

Las divisiones permiten a las organizaciones segmentar de forma segura los datos dentro de sus CXone Mpower sistema para separar diferentes líneas de negocio. Son una entidad que existe dentro de CXone Mpower. Cuando está habilitada, las divisiones afectan a todos los datos Plataforma, incluidos los scripts Studio.

Un administrador CXone Mpower debe crear divisiones en el Admin aplicación. Después de eso, puedes asignar divisiones a carpetas en Studio. La estructura de la carpeta dentro de Studio debe coincidir con la estructura jerárquica de las divisiones dentro de CXone Mpower sistema. Su administrador Plataforma a cargo de las divisiones puede ayudarlo a determinar la jerarquía.

Cada división tiene su propio conjunto de etapas de desarrollo. Si utiliza un sistema de control de versiones de terceros con Studio, el repositorio se asigna por división. Cada división puede utilizar un repositorio diferente.

Comparación de organizaciones y divisiones

La siguiente tabla resume las diferencias entre organizaciones y divisiones y su soporte para las funciones del flujo de trabajo de desarrollo.

	Organización	División
Entidad dentro de CXone Mpower	No	Sí
Requisitos de carpeta de nivel superior en Studio	Cada organización debe tener su propia carpeta de nivel superior asignada en Studio. Una organización no requiere una carpeta de nivel superior. Puede utilizar la raíz para almacenar las carpetas de la etapa de desarrollo.	Cada división debe tener su propia carpeta. La estructura de la carpeta debe coincidir con la estructura de división en Plataforma.
Apoya las etapas de desarrollo	Sí Cada organización tiene un conjunto único de etapas y carpetas de etapas.	Sí Cada división tiene un conjunto único de etapas y carpetas de etapas.
Admite la integración de sistemas de control de versiones de terceros	Sí Cada organización puede utilizar su propio repositorio.	Sí Cada división puede utilizar su propio repositorio.
Admite permisos para controlar el acceso de los usuarios a scripts y etapas	Sí	Sí

Etapas de desarrollo

Las etapas de desarrollo son el núcleo de la gestión del ciclo de vida del desarrollo de su script. Puede definir hasta cuatro etapas para que coincidan con los procesos establecidos de su empresa. Por ejemplo, si el ciclo de vida de desarrollo de su empresa tiene dos pasos, desarrollo y producción, puede configurar sus etapas de desarrollo en Studio para que coincidan. Puede personalizar los nombres de sus etapas de desarrollo para que coincidan con los nombres a los que están acostumbrados los desarrolladores de sus scripts.

Las etapas de desarrollo son hijas de una organización o una división, dependiendo de cómo esté configurado su CXone Mpower sistema. Cada organización o división tiene su propio conjunto único de etapas de desarrollo. Esto le permite personalizar los flujos de trabajo de desarrollo para cada organización o división.

En la primera etapa, debe existir una carpeta llamada principal. Esta representa la rama principal en los sistemas de control de versiones, como GitHub. Todos los scripts deben estar ubicados en la carpeta principal . Los desarrolladores de scripts pueden crear subcarpetas dentro de main para organizar scripts. La carpeta principal es necesaria si desea utilizar un sistema de control de versiones de terceros con Studio. Incluso si no planea utilizar el control de versiones, debe almacenar todos los scripts en su etapa de nivel más bajo en una carpeta principal .

Las demás etapas no tienen el mismo requisito de nombres de carpeta. Puedes tener tantas subcarpetas como quieras en las otras tres etapas y pueden tener cualquier nombre. Esto le permite utilizar subcarpetas para organizar los scripts de una manera que satisfaga las necesidades de su empresa, como por ejemplo, por versión.

Christopher Robin, el administrador Studio de Classics, Inc., está preparando las etapas de desarrollo. Classics, Inc. tiene dos líneas de negocio (LOBs), Classic Texts, que vende y alquila libros de texto a estudiantes universitarios, y Classic Cafe and Books, una cadena de librerías-cafeterías.

Comienza creando y asignándose un rol en CXone Mpower Admin que tiene permisos para crear, editar y promover en las cuatro etapas.

Christopher consulta con los gerentes de los equipos de scripting de Studio para cada LOB y aprende sobre el ciclo de vida de desarrollo de cada equipo. Luego crea dos organizaciones, ClassicTexts y ClassicCafe, cada una con sus etapas de desarrollo apropiadas en la página Desarrollo de flujo de trabajo en Studio.

A continuación, Christopher crea la estructura de carpetas en Studio. Crea un script temporal para la organización de cada LOB y elige la opción de escribir la ruta de la carpeta, nombrándola \dev\main para ambas organizaciones.

Finalmente, Christopher promueve el guión temporal a través de cada una de las etapas que creó en cada organización. No crea ninguna subcarpeta en las etapas superiores. En lugar de eso, simplemente promueve el guión a la carpeta del escenario. Para finalizar, desactiva el script temporal.

Christopher ahora puede ver la siguiente estructura de carpetas en Studio:

Café Clásico

\Desarrollador

\principal

\Pinchar

\Texto clásico

\Desarrollador

\principal

\Control de calidad

\Pinchar

Promoción y copia de guiones

Cuando un script está listo para pasar a la siguiente etapa, un desarrollador de scripts con los permisos adecuados puede promoverlo. Los scripts solo pueden ascender a la etapa siguiente más alta. También sólo pueden ser promovidos a etapas configuradas para la organización o división a la que pertenece el desarrollador del script.

Promocionar un script crea una copia del script en la etapa de destino. También copia todas las carpetas en la ruta a la ubicación del script, excepto la carpeta de escenario. Esto refuerza la estructura organizativa que crean los desarrolladores de scripts.

Tigger Tiggerson es un desarrollador de scripts en Classic Texts. Está trabajando en ScriptA, que se encuentra en /QA/Jan2025/TiggerTest/IBVoice. Lo promueve a la etapa de producción. Cuando mira la carpeta Prod, ve que la ruta completa de /Jan2025/TiggerTest/IBVoice se copió con el archivo ScriptA. La carpeta /QA no se copió porque es la carpeta de prueba.

De forma predeterminada, cuando se promocionan los scripts, se almacenan en las mismas subcarpetas en la etapa de desarrollo de destino. Los desarrolladores de scripts pueden cambiar la subcarpeta en la que se almacena el script, incluida la creación de una nueva carpeta.

Su empresa puede desarrollar procesos internos para definir las condiciones para cuando promover los guiones de una etapa a otra. Studio no rastrea estas condiciones ni valida que se hayan cumplido. Sin embargo, puedes usar roles y permisos CXone Mpower para controlar qué usuarios Studio pueden ascender a cada etapa. También puedes controlar quién puede ver, crear y editar scripts en cada etapa.

Cambios en Scripts promocionados

Seguir un flujo de trabajo típico del ciclo de vida del desarrollo de un script significa que cuando se requieren cambios en un script que se encuentra en una etapa superior, los desarrolladores de scripts deben trabajar en la copia del script que se encuentra en la etapa designada para el desarrollo. Sin embargo, si los scripts se han modificado en una etapa superior, se pueden duplicar en la carpeta de nivel más bajo. La única vez que esto debería ser necesario es si se requirió una solución de emergencia y se realizó directamente en el script en la etapa superior.

Cuando un script se promueve o se duplica a otra etapa de desarrollo, se copia en la carpeta de la etapa de destino. Si el script está en una subcarpeta dentro de la carpeta de una etapa, la subcarpeta y la ruta a ella se copian en la carpeta de la etapa de destino.

Se requieren Permisos para promover y duplicar scripts en otras etapas de desarrollo. Los desarrolladores de scripts deben tener:

El permiso para promocionar la etapa en la que están promocionando los guiones.
El permiso Crear/Editar para la etapa en la que están duplicando los scripts.
El permiso de visualización para la etapa en la que se encuentra actualmente el script.

Promover o duplicar un script a una etapa de desarrollo diferente sobrescribe la versión anterior del script si existe en la etapa de destino. Si es necesario, los desarrolladores de scripts pueden comparar scripts para determinar diferencias antes de promocionarlos o duplicarlos. También pueden ver el historial de versiones de un script y revertir a una versión anterior, si se sobrescribieron los cambios.

Control de acceso a Script y datos

Puede controlar quién puede acceder a los scripts en cada etapa de desarrollo que defina en Studio. Al utilizar los permisos asignados a los roles en Admin, puede restringir la capacidad de los desarrolladores de scripts para ver, crear, editar y desactivar scripts en cada etapa. También puedes controlar a qué etapas los desarrolladores pueden promover los scripts.

Estos permisos se aplican a organizaciones y divisiones:

Para las organizaciones, los permisos no impiden que los desarrolladores de scripts puedan ver los scripts de otras organizaciones. Si el desarrollador tiene permiso para ver scripts en la etapa de desarrollo, podrá ver todos los scripts en la carpeta de desarrollo en cada organización.
Con divisiones Separe los datos de forma segura entre las distintas líneas de negocio. Solo se puede acceder a los datos desde la división a la que pertenecen., los desarrolladores de scripts solo pueden ver los scripts en la división a la que están asignados o en cualquier división secundaria de la división a la que están asignados. Por ejemplo, los desarrolladores de scripts con permiso para ver scripts en la etapa de desarrollo en su división asignada no podrán ver las carpetas de la etapa de desarrollo de otras divisiones en el mismo nivel de jerarquía o en uno superior.

Gestión de Script con etapas

Una vez configuradas las etapas de desarrollo, los desarrolladores de scripts pueden comenzar a trabajar dentro del sistema. Debe asegurarse de que sus desarrolladores comprendan cómo trabajar dentro del sistema que ha configurado.

Al diseñar sus procesos, tenga en cuenta lo siguiente:

¿Qué etapas has establecido en Studio?
Los criterios que determinan cuándo y cómo se puede avanzar un guión a cada etapa de desarrollo.
¿Quién puede promocionar guiones y hasta qué etapa?
¿Qué hacer si es necesario modificar un script de un nivel superior? Por ejemplo, deberían trabajar en la copia de ese script en la etapa de desarrollo y luego promoverlo a través de las etapas siguientes.
¿Qué pasa si se ha realizado un cambio de corrección de errores en un script en una etapa superior? Por ejemplo, ¿debería copiarse esa versión del script en dev? Los desarrolladores de scripts pueden comparar scripts para ver cuál es la versión más nueva.
¿Alguna otra pauta o restricción que su empresa haya implementado para el desarrollo de guiones?

Control de versiones de scripts

El control de versiones le permite hacer un seguimiento y gestionar los cambios de sus scripts durante su desarrollo. Esto le permite investigar los problemas en el momento en que surgen. Si fuera necesario, puede regresar a una versión anterior del script para deshacer un cambio problemático.

Studio ofrece dos opciones para el control de versiones de scripts:

Historial de scripts: Studio conserva una serie de versiones anteriores configurables de cada script. Cada vez que se guarda el script, crea un registro de esa versión histórica. Puede ver las versiones anteriores y regresar a ellas, si fuera necesario. Esta opción se admite en Desktop Studio y Studio.
Third-Party Versión Control Systems: Studio pueden confirmar cambios en el script en un sistema de control de versiones de terceros. Actualmente, GitHub es el único proveedor admitido. Esta característica es parte de un programa de versión controlada. Póngase en contacto con su Representante de cuenta si desea más información.

Las dos opciones para el control de versiones de scripts funcionan a la par. Si utiliza un sistema de control de versiones, sigue teniendo la capacidad de ver y regresar a versiones anteriores de un script que Studio conserva. Sin embargo, GitHub no lo ve como una reversión. En lugar de ello, ve el script revertido como nuevos cambios.

De manera similar, si utiliza etapas de desarrollo en Studio, puede ver versiones anteriores de un script. Sin embargo, las versiones anteriores se limitan sólo a las versiones de cada etapa. Para ver versiones anteriores de una etapa distinta, debe ver el script en esa etapa. Para poder ver scripts de etapas diferentes, debe contar con los permisos para trabajar en esa etapa.

Datos clave sobre las etapas de desarrollo en Studio

Si su empresa utiliza divisiones Separe los datos de forma segura entre las distintas líneas de negocio. Solo se puede acceder a los datos desde la división a la que pertenecen., puede tener etapas de desarrollo separadas dentro de cada división. Studio Los usuarios sólo pueden acceder a los scripts dentro de su división que se encuentren en carpetas que tengan permiso para ver.
Si no utiliza divisiones, Studio los usuarios solo podrán acceder a los scripts ubicados en etapas de desarrollo para las que tengan permiso de visualización.
Puede configurar hasta cuatro etapas de desarrollo y personalizar los nombres para que coincidan con la terminología de su empresa. Los nombres en la página de permisos en Admin son fijos. Sin embargo, en Studio, puedes definir tus propios nombres. Los nombres que asigna a cada etapa en Studio son los que aparecen para los desarrolladores de scripts que utilizan Studio.
Dentro de cada etapa, los desarrolladores de scripts pueden crear subcarpetas para organizar los scripts.
Puede configurar una integración con un sistema de control de versiones de terceros. Esto permite a los desarrolladores de scripts enviar scripts al repositorio designado. Actualmente, el único proveedor admitido es GitHub.