Continuous Integration or Continuous Delivery (CI/CD) are common and widely used practices in software development.

Why to Use It

When deploying a configuration and doing a QA release (from DEV) or a PROD release (from QA), it is a strongly recommended best practice to use the GitLab pipelines (or alternatively any other CI/CD tool) prior to manual deployment from Pricefx Studio. This will reduce potential sources of errors significantly. By enabling the automated deployment it also will be ensured that the repository matches the partition 1:1.

The pipelines can also be used to run unit tests (TDD4C) and code quality tools (Sonar).

How it Works

When a commit is made to QA or PROD branch (or potentially to any additional environement), the pipeline is triggered. The pipeline executes a pfxpackage command line tool that reads all the Pricefx objects in the repository and deploys them to the target partition. If the object does not exist in the target partition, it gets created and if it already exists, it gets updated. A special account (typically named “pfx.deploy”) should be created on the partition with the access of a Configuration Engineer.

The automated deployment to the DEV environment typically does not make sense because each commit would most probably overwrite the configuration work in progress.

Packaging Tool deploys the objects in a smart way, that means it compares the object with the one from the partition and deploys it only if there is a change. The objects that were not changed and therefore are out the scope are listed in the log as “skipping”.

What is Part of Scope

• Deployment to QA and PROD partitions (potentially additional ones).

• Creation of logics, tables, and other objects that you see in Studio can be deployed using pipelines.

What is Out of Scope (To Be Done Manually)

• Deployment to DEV partitions.

• Existing data in the partition. Those still have to be adjusted manually during the release or by writing a migration script using https://pricefx.atlassian.net/wiki/spaces/KB/pages/3499328258 or https://pricefx.atlassian.net/wiki/spaces/UNITY/pages/4880696507.

• Deletion of the old objects is still to be done manually after the deployment; either directly on the partition or in the Fetch tool window in Studio.

Important Information and Limitations

Primary Key Fields Changes

If there is a change in the key field structure during the release, the data gets truncated. So you should potentially back up the data first, adjust and then import. Or alternatively modify the table, but create another one using a different name.

User Groups after GO LIVE

During development, the initial configuration of user groups is designed by a Configuration Engineer. After GO LIVE the security setup is owned and maintained by the customer. So it has to be ensured that the security adjusted by the customer in the partition is not overwritten by the old user groups from Git. There is a switch “keepUserGroups” in Packaging Tool that does that.

Shifting Attributes

When shifting an attribute, e.g. “Country” from e.g. attribute5 to attribute1 (P, PP, PX, C, CX, S, SX), the deployment will fail because there is a unique check on the Label and in certain moment there would be two attribute fields attribute5 and attribute1 with the same Label (“Country”) and that is not allowed.

Running Dataload Locks DS or DM Deployment

When a Data Source (DS) or Datamart (DM) schema change is being deployed and at the same time some dataload locked the DS or DM, the deployment of the schema will fail with an unknown error.

Schema Change Between Pricefx Releases

If there is a new Pricefx major release, there is a big probability that there was a field added in some object. Such a field existing on the partition is recognized as a change by Packaging Tool and therefore is deployed every time. This also pollutes the pipeline log with a lot of warning messages. So it is recommended to fetch from the target partition to Git to have the new fields in Git as well. This will help run the pipeline faster and make the log human readable again.

Troubleshooting

General Error

General error means that backend has crashed. Check the server log to find out why.

Not Authorized for Command

In case you get an error message “Not authorized for command”, make sure your deploy user account has the required user roles to manage/administer the given object.

Further reading:

See also: https://pricefx.atlassian.net/wiki/spaces/KB/pages/3499327971