Changing your PS Database Platform: The Build Phase

Posted by: Brent Martin in PeopleTools

Tagged in: Replatform

Brent Martin

In last two postings I wrote about how you might plan a project where you migrate your PeopleSoft application from one database platform to another, and how you might approach the Design phase.  I wanted to share my thoughts about the Build phase in this article.  I'll share my thoughts about the Test and Cutover phases in my next posting(s).

The Build Phase

The Build Phase is always my favorite part of any PeopleSoft project, probably because I come from a Development background.  The Build phase of a replatforming project is in some ways very straightforward, and in some ways it is more difficult.  The problem isn’t in the coding changes – it’s not too difficult to make a piece of SQL work on a different database platform -- the challenge is in Unit Testing.  Every SQL that is touched must be unit tested, and that will be the biggest part of the effort.

Most developers are used to unit testing their own work.  But it's a good idea to use a code and testing review where developers document each object change and unit test and another developer reviews the results.  Since there will be many small changes, the documentation requirement should be light, but it should include a trace file that proves that each App Engine step, PeopleCode SQL, and SQR Function was executed was tested.  How structured your process is will depend on the size and location of your team.  Insuring quality with process and documentation might not be as important in a small shop, but is critical to your success if you have a large development team located off shore.

Unit testing is the only opportunity you’ll have to actually test each piece of modified code.  Subsequent phases will test the system overall, but you will probably not achieve 100% code coverage.  Fortunately, almost all of your defects can actually be caught in unit testing of a replatforming project so you should use this to your advantage.  Defects that get missed will haunt you in later testing phases where they’ll be more visible and more expensive to fix.

Also as part of this phase, your DBA team should  execute another mock cutover using the tools and steps you decided you will use for the real cutover.  The resulting database (plus the code generated in the Build phase) will be the starting point for your first test database.

And the testing team should start building the test scripts for the subsequent test phases here.  Since we’re not changing application functionality, they should be able to leverage existing scripts from prior upgrades or implementation and enhance them for functionality that was added since the original scripts were created.

Trackback(0)
Comments (0)Add Comment

Write comment

security code
Write the displayed characters


busy