Setting up a CD pipeline
- 1 CD Pipeline for Genesys Multicloud CX private edition
- 2 Prerequisites
- 3 Procedure
- 4 Frequently asked questions
- 4.1 What repository will Genesys use to provide Helm charts to customers?
- 4.2 How many Helm charts are packaged for a Genesys Multicloud CX service?
- 4.3 How do you solve dependencies between different Genesys components during deployment?
- 4.4 Will introducing a new component or Helm parameter affect the existing ecosystem of services?
Provides recommendations on setting up a Continuous Deployment (CD) pipeline in a your cloud private edition infrastructure for automated deployments.
CD Pipeline for Genesys Multicloud CX private edition
Genesys delivers its artifacts in the JFrog Artifactory Edge repository. You can pull the containers from JFrog and push it into your pipeline stream for automated deployments. Genesys strongly recommends automating deployments for its services via a CD pipeline.
The tools you use in your CD pipeline must execute Helm charts as part of a pipeline.
Here is a quick overview of the pipeline steps involved in a typical CD environment.
- Download a container from the JFrog Artifactory Edge repository.
- Push the downloaded container into your internal container registry or to a quarantine location for security scans.
- Perform security scans on the container.
- If you are confident with the scan results, promote the container to a test/pre-production environment.
- In the test/pre-production environment, upgrade the container by referring the upgrade procedure of the specific service in its service-level documentation. You can also check out the high level upgrade procedure in this guide.
- Test the updated environment by running the automated tests.
- Once the test results are satisfying, promote the container to the next environment (if applicable to your organization) for further validation before moving to production. ImportantYour organization might have different environments other than the pre-production environment in order to test a new version of a container rigorously. Therefore, promoting a container to the next environment could mean a different environment for some users and production environment for other users.
- Upgrade the container in the production environment by referring the upgrade procedure of the specific service in its service-level documentation. If you encounter any issue with the upgrade, you can always rollback to the previous point before the upgrade by referring the upgrade procedure of the specific service in its service-level documentation. You can also check out the high level rollback procedure in this guide.
Frequently asked questions
The following FAQs answer important considerations when you are planning your CI/CI pipeline.
What repository will Genesys use to provide Helm charts to customers?
How many Helm charts are packaged for a Genesys Multicloud CX service?
Genesys typically packages one Helm chart per service. However, for specific services like Genesys Web Services (GWS), you can use the same Helm chart and deploy different services by varying the values in the Helm chart.
How do you solve dependencies between different Genesys components during deployment?
During initial deployment, we enforce a specific deployment order to be followed when you deploy Genesys Multicloud CX services. This will resolve the requirements on dependencies between different services. Once your initial deployment is up and running, you can upgrade individual services at different times.
We recommend you create a platform level CD pipeline to perform initial deployment in the required order.
Will introducing a new component or Helm parameter affect the existing ecosystem of services?
No. You can deploy the new service by following its instructions provided the core components like GAuth, GWS, Tenant service, etc. are already deployed.