SVN Repository Layout for Custom Oracle APEX Apps and Supporting Database Objects

[rraycott]

What is the best practice for creating an SVN Repository Layout/Structure that accommodates the promotion of the following file types from the physical DEVELOPMENT environment to the physical TEST/QA environment to the physical PRODUCTION environment for one large custom system with the release cycle shown below?

Source Code File Types

• APEX exports as sql files
• Oracle Forms (.fmb files)
• Oracle Menus (.mmb files)
• Oracle Reports (.rdf files)
• Oracle Database DDL files for (tables, views, triggers, packages, functions, procedures, etc.)
• Implementation Control Scripts

Release Cycle

• Frequent Limited Enhancement/Bug-Fix Releases: Most releases to TEST/QA and PRODUCTION are comprised of one to five files.
• Occasional Project Releases: A few project releases contain 25+ files.
• Never Entire System: We never need to release the entire system or a given version of the entire system.

In my research, I have found the following recommendation:

Option 1. Use Unstable Truck for Development
Related Thread: Can SVN manage my DEV QA PROD Websites

Sample Repository Layout
/trunk <-- Ongoing Development done here
/tags/tst/1 <-- Create a tag when ready for QA
/tags/prd/1 <-- Create a tag when file(s) from /tags/tst/1 have been moved into production


Option 2. ???


Option 3. ???

In the past, I have successfully implemented revision labels (DEV,TST,PRD) in StarTeam to flag the specific revision used to generate the executable in the target environment. The implementation of Subversion's non-versioned revprops appears quite limited.

Bottom-line ... my primary requirement: At any time, I need to know the exact source code revision that generated the existing executable in each of the three environments (DEVELOPMENT, TEST/QA, and PRODUCTION).

Thanks for your time,
Randy

[rraycott]

Upon further thought, I have come up with the following subversion repository layout to accommodate our promotion environment.

The primary benefit of this approach is that the trunk of each folder contains the source code files used to generate the executables in the target environment.

My goal is to keep the workflow simple for our frequent releases of one to five files.

I would appreciate your comments/warnings on the layout/approach presented below ... thanks!

Root Folder for Custom System
/src/

Top Level Promotion Environment Folders
(Note: 1, 2, and 3 were prepended to the environment to facilitate easy sorting by promotion workflow)
/src/1dev
/src/2tst
/src/3prd

Development Environment Folders (Developers live in these folders.)
(Source code file versions that were used to generate executables in the Development Environment)
/src/1dev/apex/trunk
/src/1dev/apex/tags
/src/1dev/apex/branches

/src/1dev/database/database_name1/schema1/triggers/trunk
/src/1dev/database/database_name1/schema1/triggers/tags
/src/1dev/database/database_name1/schema1/triggers/branches

Test Environment Folders (Developers have read-only access.)
(Source code file versions that were used to generate executables in the Test Environment)
/src/2tst/apex/trunk
/src/2tst/apex/tags
/src/2tst/apex/branches

/src/2tst/database/database_name1/schema1/triggers/trunk
/src/2tst/database/database_name1/schema1/triggers/tags
/src/2tst/database/database_name1/schema1/triggers/branches

Production Environment Folders (Developers have read-only access.)
(Source code file versions that were used to generate executables in the Production Environment)
/src/3prd/apex/trunk
/src/3prd/apex/tags
/src/3prd/apex/branches

/src/3prd/database/database_name1/schema1/triggers/trunk
/src/3prd/database/database_name1/schema1/triggers/tags
/src/3prd/database/database_name1/schema1/triggers/branches


General Promotion Workflow Example:
1. Developer makes change to a file in /src/1dev/... tree.
2. Developer requests that revision X of the file in /src/1dev/... be moved to the test environment.
3. The release manager uses revision X of the file in /src/1dev/... to create an executable in the test environment.
4. Upon successful execution in the test environment, the release manager uses revision X of the file in /src/1dev/... to create revision Y of the file in /src/2tst/...
5. QA tests revision Y of the file in /src/2tst/... in the test environment.
6. Upon successful QA result, developer requests that revision Y of the file in /src/2tst/... be moved from the test environment to the production environment.
7. The release manager uses revision Y of the file in /src/2tst/... to create an executable in the production environment.
8. Upon successful execution in the production environment, the release manager uses revision Y of the file in /src/2tst/... to create revision Z of the file in /src/3prd/...


Specific Promotion Workflow Example:
1. Developer makes change to /src/1dev/apex/trunk/apex_app_1.sql
2. Developer requests that revision 9 of /src/1dev/apex/trunk/apex_app_1.sql be moved to the test environment.
3. The release manager uses revision 9 of /src/1dev/apex/trunk/apex_app_1.sql to create an executable in the test environment.
4. Upon successful execution in the test environment, the release manager uses revision 9 of /src/1dev/apex/trunk/apex_app_1.sql to create revision 10 of /src/2tst/apex/trunk/apex_app_1.sql.
5. QA tests revision 10 of /src/2tst/apex/trunk/apex_app_1.sql in the test environment.
6. Upon successful QA result, developer requests that revision 10 of /src/2tst/apex/trunk/apex_app_1.sql be moved from the test environment to the production environment.
7. The release manager uses revision 10 of /src/2tst/apex/trunk/apex_app_1.sql to create an executable in the production environment.
8. Upon successful execution in the production environment, the release manager uses revision 10 of /src/2tst/apex/trunk/apex_app_1.sql to create revision 15 of /src/3prd/apex/trunk/apex_app_1.sql.

[swti6690]

The Oracle database will nullify objects if a contingent object is distorted. If you rebuild a table, the catalogs on that table will turn out to be invalid as they utilize the table’s row ids & transformation the table modify a row’s row id. It is the similar with entities similar to packages, modes operands & purposes.

http://www.inoracle.com/how-to-find-...cts-in-oracle/