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
Release Cycle
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
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
Comment