Genesys Automation – Solving Scaling Differences

genesys automationg solving for scaling difference

The ability to perform Genesys configuration automation becomes more challenging when you consider the scaling differences between production and non-production environments. Here we will discuss how to address horizontal and vertical scale of Genesys components with the use of InProd Changesets.

While your Genesys application architecture and configuration options should all be in alignment with your environments, it is common for there to be large scaling differences between them, both horizontal and vertical.

Most Genesys lab environments do not have all of the High Availability (HA) components installed, as they are often not needed during the development phase. But higher testing environments such as UAT will usually have the full HA suite. Pre-Production and production environments can be multiple sites with full HA. This results in large architectural differences between environments.

InProd promotes the concept of deploying Genesys configuration changes via a single Changesets that can traverse multiple inconsistent Genesys environments. So how do you deploy in a consistent manner to multiple environments that have such different architecture requirements?

genesys automation lab examples
Scaling differences between Genesys environments

When promoting a change between environments there are a number of factors that need to be considered for a successful deployment, scaling differences should be at the top.

With the use of Changesets, InProd is able to take a single change and promote it between environments without being modified. The Changeset can cater for environmental differences and detect issues before any changes are deployed. Now with the 1.13 release, InProd is also able to meet the different scaling requirements of each environment.

To achieve this we introduced two new concepts, the first of which is the iterator. Each action within a Changeset can be configured to be iterated, or repeated a different number of times for each targeted environment. 

Iterator value per application/environment

In the above example the backup application would be iterated 0 times (skipped) within the Dev environment, meaning it will not be installed. And an iterator value of 2 would be used for PreProd to support a deployment for Site 1 & Site 2. The iterator allows the user to determine how many instances of an object there should be for the given environment. Here we are using an Application object as an example, but any Genesys configuration object could be used.

The second concept introduced is the evaluator, which is focused on modifying the configuration parameters for each iteration of the action. Consider the Primary application, each instance of the Application name needs to be different. For PreProd, the backup application will also need to be set differently for each instance. These are just two examples of parameters that need to be modified between each iteration within the same environment.

With the introduction of the iterator and evaluator, InProd Changesets are now able to cater for extreme edge case situations such as the scaling differences discussed here. A single InProd Changeset can be used to deploy and maintain CX features within multiple Genesys environments.