Instructions provided here may be destructive. It is advised to carefully read these instructions and follow the proposed logic. If unsure, contact us via our regular support portal for help and advice.
There are a number of situations where you will need to manage your change:
When making configuration changes to a bot, you will eventually need to review your change and approve / save them
If you are running multiples bots, representing dev, preprod and production environments, to prepare work before deploying it, you will need to be able to push your changes from one environment to another
You may want to grab product updates
This page explains the tools available in the bot that make it possible for you to safely work in multiple environments.
Instructions provided here may be destructive. It is advised to carefully read these instructions and follow the proposed logic. If unsure, contact us via our regular support portal for help and advice.
There are a number of key concepts which must be understood before carrying any of the tasks listed here.
Your bot is made of products. Konverso will manage the built in products, such as kbot (the framework) and all associated solutions (ithd, gsuite, jsdm, etc.). You are in change of two products:
Your site level product: It contains information that only related to this specific instance. Typically, this is only going to be connection information that is only applicable to this particular instance.
Your customer level product: It contains information that is designed to be shared amongst all your instance. It will contains your messages, your entities, your workflows, etc. This is the part that can then be deployed to other environment.
Kbot works with a database. Everything you view inside the Administration console comes from the DB, anything that you change is saved to the database. The database contains two types of information:
Configuration: This will be also saved in GIT files
Data: This is about the Users, the Conversations and the Analytics, it will stay in the database and is not part of the git managed content.
The following diagram depicts the possible environments, their users, their DB, and their relationships through the Git repository that contains the full environment configuration.
There are two main types of changes which may be reviewed, each is an opportunity to carefully review the modification before an approval.
Any changes made in the interface is saved in the kbot database. These changes eventually need to be saved to file, such that they can be then saved to git.
A report shows the list of changes, and these can be approved or ignored.
Approved changes will be copied to file
Ignored changes will eventually be removed when the system is reloaded from files.
A Git source control is in place in the bot that allows to manage branches, version history, and merge between version.
A report provides a view of the changes that can be committed. Here again it is possible to
Save a change in git. This makes it fully persistent with a push to the remote git repository
Rollback a change.
Once the previous steps are done and your changes are safely selected and saved, you can incorporate changes that would have been made in another environment such as a prod preprod or dev kbot instance.
A view is available that makes it possible to integrate changes from another environment provided that
The remote environment is running a version lower or equal to the current version
The remote environment is running on a distinct branch.
Once you have saved your changes and integrated remotes changes you can then apply them to your bot. This will reload the bot configuration based on what is defined in your git file system.
Any change that was not saved will be erased.
The views to manage the updates are available under the Deployment menu, provided that you have sufficient privileges.
The Select report allows you to view the changes made on the bot that were not yet saved to file. The view comes in two forms:
foreground: runs quickly, in the foreground. Will however fails with a timeout if the processing takes more than five minutes
background: runs slower, in a separate process tasks. Is appropriate if the Foreground report failed due to a timeout. In general this is only required when working on large classifiers and dataset files which can cause the report to run over a duration of more than five minutes.
In this view, review carefully the changes and click on the Approve button
Note that the view show the difference in a human readable format, in the form of a text difference. For complex objects, such as the workflows, the difference may however be hard to read. It is always best for the changes to be reviewed and selected by someone who is familiar with the changes done on the project.