Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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.

(warning) 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.

Overview

There are a number of key concepts which must be understood before carrying any of the tasks listed here.

Products

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.

Database and files

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:

Overall update process

Changes review

There are two main types of changes which may be reviewed, each is an opportunity to carefully review the modification before an approval.

Database vs File

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.

File vs Git

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.

Incorporating of changes from other environments

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.

Applying changes

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.

(warning) Any change that was not saved will be erased.

Management views

The views to manage the updates are available under the Deployment menu, provided that you have sufficient privileges.

Select

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

(question) 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.

  • No labels