Many customers ask us what we offer for deployment pipelines best practices, this article aims to summarize all the options that you might have:
Staging within an Agent
You can stage your versions within a single Agent, by using Snapshots and Endpoints. Each Snapshot that you create represents a specific version and includes everything from your Build area, including Flows, NLU models, Lexicons, etc. Each Endpoint will then represent a step in your staging process/deployment pipeline. In your Endpoint you can then select which Snapshot/version you want to use and therefore use different versions across your Endpoints/stages:
Usually, your dev Endpoint will point to the latest changes in your Build area by not having a Snapshot selected, staging/test will point to the newest Snapshot you have created, and production will point to the newest approved version:
This way you can stage locally in your Agent easily. Please note that you have a limit of 10 Snapshots per Agent, you can always download older Snapshots and archive them elsewhere.
The next step is to stage across different Agents on the same environment:
This allows you to assign different people to the Agents, to limit Roles and access rights.
Your three Endpoints are each in their corresponding Agent, the Snapshots need to be moved between the Agents by downloading and uploading them:
The Intent Trainer records need to be exported from the production Agent and imported into the dev Agent, where the necessary changes will be made:
This results in the following cycle:
- build your Flows, train your Intents, etc. on dev,
- create a Snapshot, then move it to staging/testing
- after testing and approving the Snapshot you move it to production
- in certain time intervals of your liking you move the Intent Trainer records from production to dev and start again with step 1.
An additional benefit of the multi-Agent staging is to override the Connections in a Snapshot based on the stage/Agent. For this you will need to have the same Connection name in the Agent as it is in the Snapshot:
Then you only need to enable the Endpoint setting:
This allows you to target production systems in your production Agent while developing on dev systems in the dev Agent.
Merge multiple Agents
In a multi-Agent setup you can also have different teams work on different Agents at the same time and merge the Agents later on using Packages:
This allows you to have your company specific Packages (e.g., Smalltalk) that you can distribute to your Cognigy users for easy import into their existing Agents.
Multi Environment Staging
The two advantages of multi-environment staging against the multi-Agent staging are:
- you can test out new Cognigy versions before upgrading your production instance
- you can test out different environment configurations
The staging procedure remains the same as with the multi-Agent staging, your Agents are just distributed across environments.