Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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

  • #2
    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.
    Last edited by rraycott; 01-28-2011, 12:25 AM. Reason: Added database_name level to database folder.

    Comment


    • #3
      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 tables row ids & transformation the table modify a rows row id. It is the similar with entities similar to packages, modes operands & purposes.

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

      Comment

      Working...
      X