Third Party Version Control
You can use a third-party version control system with Studio. Version control allows you to track and manage changes to your scripts during their development. This allows you to research problems when they arise.
When you connect a repository to Studio, changes to each script are committed to that repository. All changes are committed to the main branch. Studio currently only supports single-branch development.
This feature is only supported in Studio. For this reason, only the JSON version of each script is saved in the version control system. Other files, such as audio prompts, are not synchronized to the configured repository.
Studio requires the ability to commit directly to main. For that reason, the GitHub policy Require a pull request before merging is not supported with Studio. If your company requires this policy, you will not be able to use GitHub for version control with Studio.
Main Branch folder in Lowest Level Stage Folder
The folder assigned to your lowest development stage must contain a subfolder called main. The lowest-level stage typically corresponds to the development stage. The main folder corresponds to the main branch, which Studio pushed files to. Having a branch folder is not required in higher level stages.
The main folder in Studio can contain subfolders. When a script developer promotes a script from the lowest stage, the entire folder structure, including the branch folder, is copied to the next stage's folder. However, because higher level stages don't require a branch folder, the path can be edited to remove the branch folder. If the branch folder is not removed, it will be copied into the folder structure of that stage.
Personal Access Tokens
Each Studio user must have a personal access token set up in GitHub. Without this, they cannot commit changes to the configured repository.
The first time Studio users attempt to commit changes to a repository, they are prompted to enter their access token for that repository. The token is encrypted and stored in CXone Mpower. After they're authenticated with the system, they are not prompted for credentials again unless Studio encounters a problem and needs to re-authenticate the user. For example, when the token expires, users must enter a new one.
The GitHub access token must:
-
Be a classic token. Fine-grained tokens are not supported in Studio.
-
Have the scope set to include user and repository permissions.
No other permissions or scopes are required. Additionally, it's recommended that the access token:
-
Only be used with Studio. Sharing access tokens between applications is not recommended.
-
Have an expiration date. The length of time the token lives us up to you.
The personal access token must be created in GitHub. An access token created in CXone Mpower will not work. See the GitHub online documentation
for information about creating access tokens.
Non-Script Files
Version control is only available for script files. Other files, such as ASR
Automatic Speech Recognition. Allows contacts to respond to prompts by speaking, pressing phone keys, or both. grammar files or pre-recorded audio prompt files, do not have saved historical versions. They also cannot be committed to a third-party version control system via Studio. To track versions of non-script files, you can use a named-based version management approach.
In the name-based version management approach, you include a version name or number in the file's name. For example, greetingPrompt_v1.wav. When you make changes to the file, you save a new copy with an updated version number. For example, greetingPrompt_v1.wav would become greetingPrompt_v2.wav.
You cannot change the names of these files in CXone Mpower. However, you can download the file to your computer, rename it, then upload the new version. You can delete versions of files you no longer need.