Enterprise Application Upgrade approach – DEV to UAT, PROD - what tables to copy?
Hello Upgrade experts,
We are planning to upgrade from Pega 7.1.4 to Pega 7.1.9 or later. As part of this, we would also upgrade CPM, CPMFS Strategic Applications. We use IAC extensively and also have BIX installed.
Question 1: The page 4 of the document "Pega719_UpgradeGuide.pdf", discusses "Typical Enterprise Application upgrade process", and talks about tables and database object to copy from DEV to UAT, as pasted below. Can someone please list the tables and database objects that need to be copied from DEV to UAT?
---------------------------------------------------------------------------------------------------------------------------
In this example, a project is initiated to upgrade and enhance an existing PRPC enterprise application to
run on Pega 7.1.9. The project requires three environments, each of which with slightly different sizing
and uptime requirements:
l Development— a small instance targeted at the development team for rule development and unit
testing, with small amounts of transaction data
l User Acceptance Testing (UAT) — a moderate instance which contains a representative sample of
production-like data where system and performance testing can be completed to certify the
application readiness for production
l Production — the full-size deployment that manages the production user population and production
transaction volumes.
By employing a different upgrade approach for each type of system, you minimize the critical production
outage window and reduce overall migration risk by ensuring that only tested and proven rules are
moved into production. The basic process design is:
1. Prior to upgrade, ensure that the Development system reflects Production.
2. Upgrade the Development system using the standard in-place upgrade process.
3. Conduct unit testing in Development and correct any issues. Exploit new capabilities that will need
to roll into Production.
4. Set up the UAT system as a copy of the Production rulebase with a suitable subset of the
transaction data.
5. When development is complete, upgrade the UAT system:
a. Replace the rulebase with the one from Development; copy the appropriate tables and other
database objects.
b. Replace the base engine classes with those from Development.
6. Test the system and verify that the UAT system executes correctly. Fix any problems in
Development and re-upgrade UAT periodically using the same table-copy technique. After testing,
the Development and UAT contains identical rulebases.
7. Complete the Production upgrade using the using the same table-copy to replace the PRPC base
engine classes.
At this point, Development becomes the Production Support system, and you can create a new
development system to commence build-out of new capabilities for subsequent release.
--------------------------------------------------------------------------------------------------------------------
Question 2: Will copying tables from DEV to UAT, override the Customer Applications rulesets in UAT?
Say DEV has CustomApp:01-05-06 after cloning from PROD. But UAT has CustomApp:01-05-07, which is yet to be promoted from UAT to PROD. Is the CustomApp:01-05-07 ruleset version in UAT overridden after copying tables and database objects as per above suggested approach? If so, what is the best way to handle this scenario, meaning retaining CustomApp:01-05-07 in UAT? (Hope exporting CustomApp:01-05-07 rules as JAR file is sufficient, to be imported after table copy)
Many thanks for your time and response.
Thanks
Raghu
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Pegasystems Inc.
IN
Hi,
If you have did a split schema upgrade then it means that the objects from the RULE schema are to be copied into the higher environments RULES schema.
But, remember if the schema names are changed in the higher environments then the references in the stored procedures / triggers / views, etc., has to be updated.
Pegasystems Inc.
IN
Thanks for the feedback Chaitra. We have Split schema - so I understand it's simply a matter of copying the entire RULES schema to higher environments.
Do you have any thoughts on the second part of the question? i.e. what are the best practices for upgrade if we have multiple parallel streams of working going on, not just upgrade project. Meaning the ruleset versions in DEV, UAT, PROD could be different at a given time, as it may not be practical to stop all Project / BAU defects work, while the Upgrade program is underway.
wellsfargo
IN
if there are two streams such as parallel development on existing system(say 6.x or so) and there is need of upgrading 6.x to 7.x environment then we have 2 options
Pre-requisite: before starting upgrade process with dev, take full db-backup and make sure there are only production rulesets versions are existing in DEv. otherwise take a ruleset level wrap with applicable data instances as well. skimming can also be considered basis feasibility
1. Out place upgrade ( for dev system)
a) you clone the existing pegarules schema (from 6.x) to another new schema (lets name PegaDATA)
b) create new schema (say PegaRULES)
c) run RulesOnlyUpgrade scripts on PegaDATA (as source) and define destination as PegaRULES schema. now the PegaRULES schema is called as golden copy. (since you will use this to copy to other environments)
d) Generate objects and execute DataOnlyUpgrade scripts on PegaDATA schema
e) Configure Datasources, Env Properties, and deploy v7EAR file in app server
f) run cleanup scripts or run optimize schema (that will delete rule tables from PegaDATA shcema which are no longer required as no longer referenced)
e) install any frameworks is suggested option as opposed to upgrade the framework.
2. Lift & Shift upgrade ( for non-dev systems such as SIT, UAT AND PROD)
pre-req: take full db copy before upgrade
if there are two streams such as parallel development on existing system(say 6.x or so) and there is need of upgrading 6.x to 7.x environment then we have 2 options
Pre-requisite: before starting upgrade process with dev, take full db-backup and make sure there are only production rulesets versions are existing in DEv. otherwise take a ruleset level wrap with applicable data instances as well. skimming can also be considered basis feasibility
1. Out place upgrade ( for dev system)
a) you clone the existing pegarules schema (from 6.x) to another new schema (lets name PegaDATA)
b) create new schema (say PegaRULES)
c) run RulesOnlyUpgrade scripts on PegaDATA (as source) and define destination as PegaRULES schema. now the PegaRULES schema is called as golden copy. (since you will use this to copy to other environments)
d) Generate objects and execute DataOnlyUpgrade scripts on PegaDATA schema
e) Configure Datasources, Env Properties, and deploy v7EAR file in app server
f) run cleanup scripts or run optimize schema (that will delete rule tables from PegaDATA shcema which are no longer required as no longer referenced)
e) install any frameworks is suggested option as opposed to upgrade the framework.
2. Lift & Shift upgrade ( for non-dev systems such as SIT, UAT AND PROD)
pre-req: take full db copy before upgrade
a) copy golden copy (PegaRULES) into new schema
b) run dataonlyupgrade on pegarules (of 6.x schema) and generate objects
c) Configure Datasources, Env Properties, and deploy v7EAR file in app server
d) run cleanup scripts or run optimize schema to delete no longer required rules in old schema (6.x) from now on its only data schema.
this way, you will have existing environments asis for ongoing development and you are upgrading to pega7 env...after this you can do code retrofitting.
Pegasystems Inc.
IN
Thanks Rakesh for the useful info on two approaches.
In our case, we are already on Pega 7.1.4 + CPM FS 7.1.2. Plan to upgrade to Pega 7.2 + CPM 7.1.4
We are using Split schema in current system. I guess the approaches described remain same from Pega 7.1.x to Pega 7.2