While working with Koji, you will need to apply various changes and deploy new products or bots. This page explains the main concepts you need to understand in order to maintain your Koji environment and describes the tools available in the bot that help you work safely in multiple environments.
| Table of Contents |
|---|
When do I need to manage changes?
There are a number of situations where you will need to manage your changechanges:
When making configuration changes to a modifying configuration of your bot, at some point you will eventually need to review your change changes to approve and approve / save them.
If you are When running multiples multiple bots , representing that represent dev, preprod, and production environments, you will need to prepare and check the work before deploying it, . Also you will need to be able to push your changes from one environment to another.
You may want to grab When 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.
Overview
There are a number of key concepts which must be understood before carrying any of the tasks listed here.
...
are available, you will need to apply them.
Before taking actions
Instructions provided on this page might be destructive. We recommend that you study these instructions carefully and follow the described logic. If you are unsure about performing any actions, please, contact us via our Support Center and we will be happy to help.
Key concepts
To successfully carry out the tasks described on this page, you must understand a number of key concepts.
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: a site level product and a customer level product.
Site level product: it contains information that is related only to this specific instance. Typically, this is just the connection information that is only applicable to this particular instance.
Customer level product: it contains information that is designed to be shared amongst all your instances. This product contains your messages, entities, workflows, etc. This is the part that can be deployed to other environment.
Database and files
Kbot works with a database. Everything you view inside the Administration console comes from the DB, and anything you change is saved to the database. The database contains two types of information: configuration and data.
Configuration: this is also saved in Git files.
Data: this is about users, conversations, and analytics. Data stays in the database and it is not a part of the Git managed content.
Configuration flow
The diagram below displays possible environments, their users, DB, and relationships through the Git repository that contains the full environment configuration.
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Update procedure
Reviewing changes
There are two main types of changes which may be reviewed, each is that you can review. Each type provides you with an opportunity to carefully review the modification carefully before an approvalyou approve it.
Database vs
...
file
Any changes that are made in the user interface is are saved in the kbot Kbot database. These changes eventually need to Then these changes must be saved to a file, such that so they can be then saved to gitGit.
A The DevOps > Deployment > Manage changes > Select report shows the list of changes, and these can be approved or ignoredso you can decide whether to approve or ignore them.
Approved changes will be are copied to a file.
Ignored changes will eventually be are removed when the system is reloaded from files. .
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 DevOps > Deployment > Manage changes > Git synchronization report shows the changes that can be committed. Here again it is possible to
Save a change changes in gitGit. This makes it fully them persistent with a push to the remote git Git repository
Rollback a change.
...
.
Rollback your changes.
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Integrating changes from other environments
Once the you have finished previous steps are done and your changes are safely selected checked 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 other environments, such as preprod, prod, or dev Kbot instance.
The DevOps > Deployment > Manage changes > Integrate report helps you integrate changes from another environment, provided that:
The A remote environment is running a version lower or equal to the current version.
The A remote environment is running on a distinct branch.
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Applying changes
Once you have saved your changes and integrated remotes remote changes, you can then apply them to your bot. This will reload It reloads the bot configuration based on what is defined in your git Git file system.
To do so, use the The DevOps > Deployment > Manage changes > Apply updates report.
| Note |
|---|
...
Changes that |
...
are not saved will be erased. |
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Change management tools
To review and manage changes, use the tools that are designed for this. Go to DevOps > Deployment > Manage changes to see them. Note that you must have proper privileges to access these tools.
...
Select
The Select report allows you to view the changes made on the bot that are not saved to a file yet.
The report shows the difference in a human readable format, in the form of a text difference. For complex objects, such as workflows, the difference might be hard to read. It is best for the changes to be reviewed and selected by someone who is familiar with the changes done on the project.
The view comes in two forms:
Foreground: this report runs quickly in the foreground. It fails with a timeout if the processing takes more than 5 minutes.
Background: this report runs slower in a separate process task. It is appropriate if the foreground report fails due to a timeout. In general we recommend to use this report only when classifiers were changed greatly or a lot of articles were added. So if you have huge changes, pick a background report.
Review the changes carefully and click the Approve and save button if you want to keep the changes.
Git synchronization
This report allows you to commit, push, and pull the changes to a remote Git repository.
The report does not get refreshed automatically after actions take place. To get an updated status, please refresh the report manually by clicking the Refresh button.
In general, the recommended set of actions is:
Review the changes and approve them (commit) or reject them (rollback). To perform these actions click the corresponding icon.
...
Pull the changes from remote servers by clicking a down arrow.
...
Push the changes to a remote server by clicking an up arrow.
...
When you finish reviewing, there should be no warnings, changes, or suggested actions.
Integrate
Your bot is typically one bot in a deployment chain such as:
...
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. Production host might have some changes that appeared during the day-to-day bot usage, such as FAQ articles or AI patterns, created by a knowledge manager while they were busy with conversation training. You might want to get these changes, since FAQ articles can help you test the search performance, for example.
Retrieve the changes made in a development environment. This is the expected path. Developers work on dev and commit/push their changes after they are done. You could merge the changes to your pre-production environment to validate them before implementing them in production.
Sometimes it can be useful to transfer a data base (a conversation history, for example) from prod to preprod in order to carry out some improvements. Real customer data can help to test various tools and check real-life results.
Apply
In this tool you can:
Load the configuration from files, replacing the content in the DB with the content from 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 actions in this report results in a downtime of a few minutes.