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 7 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:

  • 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.

Configuration flow

The following diagram depicts the possible environments, their users, their DB, and their relationships through the Git repository that contains the full environment configuration.

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.

Git Synchronization

This view will allow you to commit, push and pull to the remote Git repository.

Note that the view does not automatically refresh after actions, refresh the view to get an updated status.

In general, the recommended set of actions is:

  • review the changes, approve them (commit) or reject them (rollback)

  • pull the changes from the remotes servers, if any, these will be highlighted by a down arrow

  • push the changes to the remote server, this action will be highlighted by an up arrow.

In general, you should end with a view without any warnings, changes, or suggested actions.

Integrate

Your bot is typically one bot in a deployment chain such as:

Production → Pre-production → Dev

Provided that the versions meet certain requirements, you can merge the changes from the sibling environments. For example, if you are in Pre prod, you could:

  • Retrieve the changes made in production. While it is not usual to have configuration changes done directly in production, this may occur for simple things like messages or corrective actions that would have been done directly inside the production environment.

  • Retrieve the changes made in a development environment. This is the expected path. Developers will work on dev and commit/push their changes after they are done. You could merge the changes to your preproduction environment to get a chance to validate them before later retrieving them in production.

Apply

As stated in the view, this action will:

  • Load the configuration from files, effectively replacing the content in the DB with the content found in the files.

  • Retrieve possible corrections and enhancements made on the product

  • Restart a few processes to ensure all changes are fully loaded and in place in the product

Executing the action in this view result in a downtime of a few minutes.

  • No labels