Automatic Deployment - Deleted Rules in the source env aren't deleted in the target env
We are performing a daily deployment from our dev environment into the next stage (test environment). We have a daily job that calls prpcUtils. In this job we use a product rule which references the latest and unlocked rulesets and copies all rules from this rulesets to the test environment. We now detected that rules that have been deleted in the source environment and that where already copied to the target environment, won't be deleted in the target environment. We are looking for an automated way to determine those rules: rules that don't exist any more in the source env but still exist in the target env, so that we can delete those rules also from the target environment. Something similar to the Rulebase Compare feature in Pega but in an automated way.
You could query the the pr4_rule_vw table to identify differences between the two environments; There will always be some differences but as long as you have sufficient filtering it should give you a clearer picture.
I wouldn't suggest deleting rules as a matter of course though, this should be the exception not the norm.
Yes the import process doesn't delete the rules which were deleted in the source environment as this utility main task is the create/update the source environment rules into target environment.
There is no ready made utility that helps you to automate these, as the Rulebase Compare refactor utilities can be accessed from UI only. That is the reason generally the users will keep track of the pzInsKey's of the rules that were being deleted in the source environment manually, so that they can delete them in the target environment at later point.
If not for RULES, this feature should be available for DATA atleast.
Because, for a RULE instance we could withdraw it in source environment which would get auto deployed in target environment.
Whereas, for a DATA instance, there is no other way but to delete it. Example: You had once created a Access-Role-Object and propagated to target environment. a later requirement dictates that you should delete the ARO for that particular class so system refers to the parent class during runtime
I am thinking the only way to handle this is a supplementary sql file to cover such DELETE to be included in the release. The contents of the file will need to be manually checked in. Is there a better way of doing this?