Best practice for CPF Merge and version control
I have been reviewing the details on the CPF Merge functionality offered in IRIS:
I love the frequent mentions of versioning the CPF merge files in Source control. One thing that is not yet clear to me is how this would work for rolling back a change:
"That way, assuming you version and store the merge files you employ, you can maintain a record of the configuration of each instance through time, enabling rollback if required, and avoid the possibility of configuration merge overwriting changes made by other means"
As I understand it, the CPF Merge file contains the changes from the default CFP file, so it you change the routine buffers in version one of the file, you could then change gmheap in version #2 by adding a new line to what was in #1. If you change the Web Application Security in #3 and then realize that it was a mistake and need to roll it back quickly, if you roll back in Source control to #2, I believe that would just take the lines changing the security out of the CPF Merge file, but would applying that merge change it back to the prior setting? Since that change is already merged into the main CPF file wouldn't the user have to be versioning the resulting CPF file following each merge in order to be able to do a rollback to a prior configuration? Or am I missing something?
Note- this is specially for updating running instances and not for spinning up new instances (obviously the rollback would work in that case as the new instance would have never received the change).
cc: @Luca Ravazzolo