This article describes the process by which Pricefx configuration is deployed to a partition and how versions progress from development to user acceptance testing and finally to production.

The partitions usually follow the naming convention customer-dev for development version, customer-qa for a user acceptance partition and customer for the production environment. In this article we will refer to them as DEV, QA and PROD.

The information described here is relevant mainly for the Pricefx team, but could also be used by partners and customers.

Deployment to DEV

When a developer tests a newly prepared configuration, they deploy some configuration parts (usually logic changes) to a development partition. Such a deployment enables testing, within a real environment, from a user perspective.

There is always the possibility that multiple developers will be simultaneously working on different features and have a need to test their individual features. Given that there exists only one DEV partition, the team must recognize and discuss testing arrangements to avoid conflicting configurations.

Manual vs Automated Deployment

Both manual and automated deployment have their advantages and disadvantages.

The main advantage of the Manual approach is the complete control over the process - the user can compare the new configuration version with the existing partition version and ensure that the deployment will not break any data. This is a particularly sensitive issue when deploying changes of table metadata. Remember, Unit Tests are not able to catch potential metadata related issues.

The automated process, has the advantage that it’s done regularly based on a schedule, without user involvement.

The automated deployment is done using CI/CD software, in Pricefx case we use GitLab pipelines.

The packaging tool is a command line tool, which can perform the operations Fetch & Deploy on the configuration - using exactly the same project structure and configuration metadata as Pricefx Studio.

Automated Deployment do DEV

Developers typically use Studio for deployment of their configuration changes to the DEV partition.

Some teams choose to set up an automated deployment of the dev branch to the DEV partition (typically scheduled over the weekend). This procedure ensure’s that the DEV partition has the proper configuration and is "clean" for further development and testing.

Deployment to QA and PROD

When moving configuration versions from DEV to QA and PROD, the mandatory rule is - it must be done in Git first, and then deployed to the partition.

Which configuration changes will be moved from DEV to QA and from QA to PROD is always decided between the development team and the customer. The schedule of the change must be always discussed with the customer.

Usually there’s one team member dedicated to performing of the changes:

• Merge of the changes from dev to qa branch (or qa to master branch).

• Manual deployment of the configuration from Git branch to the partition (including the comparison of the changes between partition and branch, to ensure the deployment does not cause any data loss).

Automated Deployment to QA

Although technically possible, the automated deployment to QA should be discussed with the customer to ensure their QA team performing the UAT testing is not harmed by such deployments.

Generally, the deployment of new versions to QA is done only once their QA team has completed testing of the previous version. Moving prior to the QA team completing testing will cause obvious issues.

References

• Knowledge Base

• Manual Configuration Deployment with Studio