This section provides an overview of projects and discusses how to:
Use multiple databases for development.
Use distributed development environments.
You can use all levels of Change Control with or without also using projects. If you decide not to use projects, you rely on the Locked Objects dialog box, rather than the project workspace, to identify locked definitions. The dialog box provides a better overall view of locking status because it shows all of the PeopleSoft Application Designer definitions in the database, not just those in the current project.
Use projects to track the definitions that are changed as part of a change or feature request. This set of definitions is commonly referred to as the change set. The Options dialog box has an option to insert a definition into a project when it is modified and saved. If you start with an empty project, this option provides an easy way of tracking the change set for this incident. When the change request is completed, the project contains everything that is associated with the change. You should also use the Comments field in the Project Properties dialog box to list any external definitions, like COBOL or Structured Query Report (SQR) modules, that must be migrated with this change.
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.
Using Distributed Development Environments
You should use a master development database even if each development team works on its own copy of the database. Developers should lock down the definitions on which they intend to work in the master development database, and then copy those modules to their private databases. This method ensures that no other developer makes a change to those definitions while they are checked out.
When a developer is ready to copy changes back to the master development database, you check the Change Control history of the locked definitions in the master development database. Do this before using upgrade copy to migrate them back, just in case a Change Control administrator has overridden a lock and made a change while the definitions were checked out.
Note: Change Control administrators should always notify the developer who has a lock on a definition before they override to avoid unexpected surprises later.