Best Practices: Building a Deployment Pipeline for Cognigy AI Agents

Many customers often ask us for advice on the best practices for deployment pipelines.

This article outlines key best practices to help you establish robust and efficient pipelines.

There are three different approaches:

• Single-Project Staging
• Multi-Project Staging
• Multi-Environment Staging

Single-Project Staging

You can stage AI Agent versions within a single Project by using Snapshots and Endpoints:

• Each Snapshot you create represents a specific version of your Project and includes most of the Project's components, such as Flows, Nodes, and NLU models.
• Each Endpoint you create represents a step in your deployment process. In each Endpoint, you can select which Snapshot, a version of the Project, you want to use.

For example, consider a set of Endpoints configured for Webchat v2:

- 00 - Dev Webchat. As a rule, your dev Endpoint points to the latest changes in your Project by not having a Snapshot selected.



- 01 - Staging Webchat. Your staging Endpoint points to the newest Snapshot you have created.



- 02 - Production Webchat. Your production Endpoint points to the newest approved version of the Snapshot.

Snapshots are helpful for testing changes or regression checks without affecting the production version. There's a limit of 10 Snapshots per Project. To manage older versions, you can download them and store them externally for future reference.

Multi-Project Staging

You can stage versions across different Projects in the same environment. This approach allows you to assign different people to the Projects to limit roles and access rights.
Name your Projects in such a way that each one reflects the development stage of your AI Agent.

For example:

• Dev Demo
• Staging Demo
• Production Demo

To move versions between projects, you should create a Snapshot in one Project, download it, and then upload it to another Project.

The Intent Trainer records need to be exported from the production Project and imported into the dev Project, where the necessary changes will be made.

Multi-Project Staging Life Cycle

The following life cycle applies to Multi-Project staging:

1. Build your Flows and train Intents within the development environment.
2. Create a Snapshot of your Project and move it to the staging environment.
3. After successful testing, move the Snapshot to the production environment.
4. At regular intervals (or as needed), migrate Intent Trainer records from the production environment to the development environment and restart the training process from the beginning.
   
   

Override Connections

An additional benefit of Multi-Project staging is the ability to override the Connections in a Snapshot based on the stage. To do this, you need to use the same Connection name in a Project as it is in the Snapshot. 

For example:

The connection is named Emailing in the Dev Demo Project.

The connection is named Emailing in the Production Demo Project.

Then you only need to enable the Endpoint setting:

This approach helps you target production systems in your production Project while developing dev systems in the dev Project.

Merge multiple Projects

Within Multi-Project staging, teams can work on different projects simultaneously and merge AI agents using Packages, creating company-specific Packages for distribution to Cognigy users.

Multi-Environment Staging

This approach is only available to customers who opted for a Private SaaS hosting model with a dedicated non-production environment. The means that a completely dedicated kubernetes cluster is created and maintained for each of the production and non-production stages with complete logical and physical separation, being run as two separate and dedicated Cognigy systems.

There are several key advantages of Multi-Environment staging compared to Multi-Project staging:

• You can validate the compatibility of new software versions of Cognigy with your projects before upgrading a production environment. This flexibility allows you to identify potential issues before they impact end users.
• System software version release cycles can be tailored to the specific needs of your organization.
• There is no chance to affect production traffic by any testing on a dedicated non-production system.

The deployment procedure remains the same as with Multi-Project staging. Your AI Agents are simply distributed across different environments but snapshots or packages can be used to migrate projects between stages. Although coming at a higher complexity and cost to other deployment models, this approach is the most effective at greatly reducing the chance of an interruption to end user experience on production systems.