Using Multiple Databases for Development

Managing change in a single database environment is straightforward, but very few PeopleSoft users operate in a single database environment. The classic development model uses three databases: development, test, and production. You apply all changes to the development database. After you unit-test the change, migrate the change set to the test database, where it goes through more rigorous testing. Usually, you would run one or more regression test suites to ensure that you resolve the issue that you intended to resolve with no unwelcome side effects. Finally, that change set is migrated into the production database. If you find a problem at any stage in the process, the incident is sent back to development and the process begins again.

This model assumes that the development database is the master database. You can use the Change Control locking feature to lock down the modules on which you and other developers are working. When developers complete the changes in the development database, they notify the Change Control administrator and use the upgrade copy facility to copy the change set into the test environment. As long as you use the technique that is described previously in this section, the project should contain the entire change set. The system tracks all of the documentation for the change in the development database. The only information that appears in the test and production databases is a history line indicating it was copied. Definitions move only in one direction in this model: from development to test, then from test to production.

Note:

The only case in which you can copy a definition back to development from either test or production is if a problem must be recreated and another change was already made to the affected definition. Do this with extreme care because upgrade copies are destructive and cannot be undone if you discover that you overlaid another developer's change. For this reason, you should apply changes directly to test or production databases only rarely.

Note:

This Change Control model is just one that you can use. We provide it to give you an idea of how you can implement Change Control in your environment. While you do not need to follow this model exactly, you should implement a Change Control model that enables you to track changes to the system and prevent developers from overwriting each other’s changes.