Migration of Peoplesoft Objects:
1. Overview:
The PeopleSoft Object migration process is the method of “moving”, or migrating objects and lines of code from the development to the production environment in phases, after thorough functional testing.
The PeopleSoft Object migration process is the method of “moving”, or migrating objects and lines of code from the development to the production environment in phases, after thorough functional testing.
The PeopleSoft DBA generally performs migrations to the production environment at the request of an application developer or functional analyst. Developers are permitted to perform migrations between the development and test environments. Developers need DBA assistance when updating the database with new tables, views, and PeopleSoft Security other than non-development environment.
After unit testing the change in the Development environment, the PeopleSoft DBA is notified with a request to move the project from the Development environment to the Test environment. The PeopleSoft DBA uses the upgrade copy facility to copy the changed set of objects into the Test environment. The migrated project in the Test database undergoes more rigorous testing. Usually, one or more regression test sets are run to ensure that the issue is resolved and that the change does not adversely effect mainstream processing. Finally, the project is migrated into the Production database. If a problem is found at any stage in the process, then the issue is sent back to the developer and the process begins all over again. It is highly recommended that PeopleSoft objects move from development to test environment and then from Test to Production.
2. Assumptions:
Listed below is a set of variables that are referred in the document and what they denote:
DMO – Demo Database
DEV – Development database
TST – Test database
PRD – Production database
3. PeopleSoft Object Migration Steps
The following section describes the steps for migrating changes and fixes to the production environment and the use of the various databases in each phase.
Step 1 – Copy PRD
In this step, the PeopleSoft Administrator makes copies of the PRD database to create new DEV and TST databases. These databases should represent the current client configuration in the Production environment, with test transactions in place to facilitate the testing of changes and fixes.
Step 2 – Develop / Install Changes
Client-requested changes are developed and Unit Tested in the DEV database. PeopleSoft patches & fixes are installed and tested in DMO, then in DEV. The DEV environment is where problems and issues are identified and resolved, and where the Change Control scripts are developed which will ultimately be applied to TST, and PRD databases via change control.
Client-requested changes are developed and Unit Tested in the DEV database. PeopleSoft patches & fixes are installed and tested in DMO, then in DEV. The DEV environment is where problems and issues are identified and resolved, and where the Change Control scripts are developed which will ultimately be applied to TST, and PRD databases via change control.
Step 3 – Migrate Changes to TST
Using the Change Control scripts, the PeopleSoft DBA moves Objects, Lines of Code and translate values as per the request from the developer or as required by the PS patch/fix from DEV to TST.
Using the Change Control scripts, the PeopleSoft DBA moves Objects, Lines of Code and translate values as per the request from the developer or as required by the PS patch/fix from DEV to TST.
Step 4 – Test Changes in TST
Perform Integration Testing of all changes in the “clean” TST database. This process tests the validity of the changes/fixes, and the validity of the Change Control scripts.
Perform Integration Testing of all changes in the “clean” TST database. This process tests the validity of the changes/fixes, and the validity of the Change Control scripts.
Step 5 – Create SYS/QA (Depending Upon Client dB standard)
Make a copy of the Production database (PRD) into SYS/QA. The SYS/QA database provides a final check of the changes and Change Control scripts using the “live” database contents.
Make a copy of the Production database (PRD) into SYS/QA. The SYS/QA database provides a final check of the changes and Change Control scripts using the “live” database contents.
In the absence of a SYS/QA database, all system and final testing will be done in TST. The TST database provides a final check of all changes and Change Control scripts using the “live” database contents. In such instance, using the Change Control scripts, the PeopleSoft DBA moves all changes from DEV to TST.
Step 6 – Run Scripts to SYS/QA (only if SYS/QA exists)
Using the Change Control scripts, the PS DBA moves all objects, lines of code and translate values from TST to SYS/QA.
Using the Change Control scripts, the PS DBA moves all objects, lines of code and translate values from TST to SYS/QA.
Step 7 – Perform Final Testing in SYS/QA (only if SYS/QA exists)
This is similar to the testing done in Step4 in the TST database, only this time it is done against a snapshot copy of the production database. This final test verifies once again that the migration scripts are correct, and that no changes have occurred in the production database that have escaped the Change Control process, such that the testing done in TST is invalid.
This is similar to the testing done in Step4 in the TST database, only this time it is done against a snapshot copy of the production database. This final test verifies once again that the migration scripts are correct, and that no changes have occurred in the production database that have escaped the Change Control process, such that the testing done in TST is invalid.
Step 8 – Run Scripts to PRD
Using the Change Control scripts, the PS Apps DBA moves all changes from TST to PRD. Note: To “state the obvious”, it should be ensured that a successful backup copy is made of the PRD database before the migration scripts are run.
Using the Change Control scripts, the PS Apps DBA moves all changes from TST to PRD. Note: To “state the obvious”, it should be ensured that a successful backup copy is made of the PRD database before the migration scripts are run.
Step 9 – Delete SYS/QA (only if SYS/QA exists)
Once it is assured that all changes have been successfully installed in PRD, and the production system is stable and operating properly, the SYS/QA database may be deleted.
Once it is assured that all changes have been successfully installed in PRD, and the production system is stable and operating properly, the SYS/QA database may be deleted.