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
...
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 it contains information that is related only related to this specific instance. Typically, this is only going to be just the connection information that is only applicable to this particular instance.
Your customer Customer level product: It it contains information that is designed to be shared amongst all your instanceinstances. It will This product 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, and anything that you change is saved to the database. The database contains two types of information: configuration and data.
Configuration: This will be this is also saved in GIT Git files.
Data: This this is about the Users, the Conversations and the Analytics, it will stay users, conversations, and analytics. Data stays in the database and it is not a part of the git Git managed content.
Configuration flow
The following diagram depicts the below displays possible environments, their users, their DB, and their relationships through the Git repository that contains the full environment configuration.
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Overall update process
...
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 | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
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 changeyour 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.
...
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. Any change that was
To do so, use the The DevOps > Deployment > Manage changes > Apply updates report.
| Note |
|---|
Changes that are not saved will be erased. |
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Management views
The views to manage the updates are available under the Deployment menu, provided that you have sufficient privileges.
...
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 were are not yet 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:
foregroundForeground: this report runs quickly , in the foreground. Will however It fails with a timeout if the processing takes more than five 5 minutes.
backgroundBackground: this report runs slower , in a separate process taskstask. Is It is appropriate if the Foreground foreground report failed fails due to a timeout. In general we recommend to use this is report only required when working you work on large classifiers and dataset files, which can cause the report to run over a duration of more than five 5 minutes.
In this view, review carefully Review the changes carefully 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.
Git Synchronization
This view will allow and save button if you want to keep the changes.
Git synchronization
This report allows you to commit, push, and pull the changes to the a remote Git repository.
Note that the view The report does not get refreshed automatically refresh after actions , refresh the view to 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 Review the changes , and approve them (commit) or reject them (rollback)pull . To perform these actions click the corresponding icon.
...
Pull the changes from the remotes servers, if any, these will be highlighted by remote servers by clicking a down arrow.
...
push Push the changes to the a remote server , this action will be highlighted by clicking an up arrow.
...
...
When you finish reviewing, there should be no warnings, changes, or suggested actions.
...
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. While it is not usual to have configuration changes done directly in production, this may might occur for simple things like messages, or corrective actions that would have been are 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 pre-production environment to get a chance to validate them before later retrieving implementing them in production.
Apply
As stated in the view, this action willIn this tool you can:
Load the configuration from files, effectively replacing the content in the DB with the content found in 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 the action actions in this view result report results in a downtime of a few minutes.