An Example of Using the Oracle9i Designer Repository for … · functional, data access, and data...

An Example of Using the Oracle9i Designer Repository for Software Configuration Management An Oracle White Paper July 2002

An Example of Using the Oracle9i Designer Repository for Software Configuration Management

Executive Overview.......................................................................................... 3 Introduction to Configuration Management Practices ................................ 3

Assumptions .................................................................................................. 4 Supported Promotion States............................................................................ 5 Roles Identified.................................................................................................. 5

Content Focused Roles ................................................................................ 6 Environment Focused Roles....................................................................... 7

Example Scenarios ............................................................................................ 8 Conduct Development Activity in a Team Development Environment ................................................................................................. 9 Conduct Development Activity in a Personal Development Environment ................................................................................................. 9 Promote From Development to System Testing................................... 10 Promote From System Testing to Acceptance Testing ........................ 11 Conduct Acceptance Test Corrections.................................................... 11 Instantiate Training Environment............................................................ 13 Finalize Acceptance Test for Deployment.............................................. 13 Promote From Acceptance Test to Production..................................... 14 Conduct Production Corrections ............................................................. 14

Conclusion........................................................................................................ 15

An Example of Using the Oracle9i Designer Repository for Software Configuration Management Page 2

An Example of Using the Oracle9i Designer Repository for Software Configuration Management

EXECUTIVE OVERVIEW Introducing version control and release management into a software development environment requires more than just the deployment of a source code control or software configuration management (referred to as configuration management in this white paper) tool. It requires a clear understanding of the items under control and the roles, responsibilities, procedures and mechanisms for implementing that control. Implementing organizational change is therefore usually more important, and subject to more failure, than implementing configuration management tools.

However, making use of a flexible but comprehensive configuration management tool that can be easily integrated into the development environment improves the chances of success. The Oracle9i Designer Repository provides such a tool for both Designer model based and for file based application source code.

Note – The Designer Repository is now also available as a separate component from Designer in the Oracle9i Developer Suite (9iDS), called Oracle9i Software Configuration Manager (SCM).

Unfortunately, each enterprise has its own specific needs due to differences in the organizational and technical environment. Therefore, there does not seem to be a “one size fits all” or “best practice” solution that can be successfully provided. In its place, this paper provides an example of configuration management practices that draw from a number of implementations. These practices could be successfully deployed “as is”, but are primarily here as a starting point for an enterprise to define its own appropriate configuration management policies, procedures, roles, responsibilities, and mechanisms.

INTRODUCTION TO CONFIGURATION MANAGEMENT PRACTICES The definition of configuration management practices in a software development environment starts with the identification of scenarios, or “use cases”. These scenarios describe in general terms how, when, why, and by whom a set of software elements gets instantiated as a specific promotion state and then correspondingly how and when they may move to their next state(s). Additional details that make up configuration management practices can then be drawn from these scenarios. These include:


• Promotion States – which promotion states need to be recognized, and which state transitions are allowed for.

• Roles – including the active roles, control roles, and definitional roles that take part in configuration management practices.

• Policies – which items are controlled for each promotion state or state transition and under what conditions. This includes the basis of the corresponding scenario and the expected result.

• Procedures – the activities, and configuration management tool actions, employed against each type of controlled item to achieve the policy results. Also identified are the roles responsible for carrying out each activity.

• Tool Mechanisms – the required structures, lists, content, functionality, and utilities required to support configuration management procedures.

The configuration management procedures and mechanisms are of course dependent on the capabilities of the configuration management tool used.1 Roles and responsibilities are also constrained by the available staff, skills, and management structures. Therefore, the definition of configuration management practices for an environment becomes an iterative process.

In order to shortcut this process, and assist organizations in developing their own unique configuration management practices, this document describes a series of reasonably typical configuration management scenarios or policies. It defines the roles and responsibilities for each scenario’s procedures. It also describes the Designer Repository mechanisms that would be used to support the procedures. A number of assumptions underpin the configuration management practices presented as documented below. This was done to limit this document to an understandable set of basic scenarios.

Assumptions The assumptions about the configuration management environment and its requirements represent enterprise specific restrictions. These restrictions are unique to any organization but serve to limit the number of scenarios and contingencies that must be allowed for. In this example, they include:

• Multiple development teams working concurrently on a set of discrete application systems. The application systems have some, but not a great number of, item interdependencies.

• Both structured items (Designer model elements) and unstructured items (files of any type) need to be controlled. An application system release will be constructed from both types of source items held as elements in the Designer Repository.

1 Refer to the Oracle white paper “Software Configuration Management with Oracle9i Designer” for more information on Designer Repository concepts and capabilities.


• There is a limited requirement for parallel item development. Any parallel development is for a specific purpose (i.e. a production correction) and the results are merged together as soon as it is feasible.

• The need for exclusive private locks on elements is confined to later stages of development, so the need for personal development areas is limited and not widespread. In most cases team-wide access to elements is preferred.

• File based elements will be uploaded/downloaded to the appropriate files system directory as required. This is in contrast to editing files directly from a repository or making use of folder container mappings to synchronize file elements (both of which are Designer Repository capabilities).

• The enterprise deployment environment (i.e. for acceptance testing, for production) has a consistent technology stack for all its application systems.

For clarity, no restrictions have been placed on the number of roles, nor on their focus or breadth. It is further assumed that each role may be partly or wholly filled by one or more actual staff members. There is also no requirement for distributed or remote application development. All the development teams access the same Designer Repository database instance.

SUPPORTED PROMOTION STATES The policies, procedures, and mechanisms act on software elements within a series of promotion states. These promotion states correspond to supported software development and deployment environments.

Figure 1 represents the promotion states/environments that are described in the example configuration management practices.

ROLES IDENTIFIED The following are the Designer Repository related roles required within a Designer based application development environment. Not all of these roles are required for a purely file based development environment, but are included here for clarity.

The roles are of two types - content focused and environment focused. Content focused roles are concerned with application elements being developed. Environment focused roles are concerned with the infrastructure to support the development activity.

The roles have different breadth of focus as well. The Project roles deal with the elements for a specific application project. The Transition roles consider issues across project boundaries. The Enterprise roles have responsibilities that are irrespective of any specific application project.


APP_DEV APP_FNCTST APP_PRD

J:\app\dev\ -fmb -mmb -sql -ddl

J:\app\fnctst\ -fmb

-mmb -sql -ddl

J:\app\prd\ -fmb -mmb -sql

Tools

J:\app\ret -fmb -mmb -sql -ddl

APP_RET

Development Personal OR Team

Functional / System Test

ProductionCorrection

Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST

Integration /Acceptance

Test

J:\app\inttst\ -fmb

-mmb -sql -ddl

Repository Model Source

APP_RET

-ddl

APP_PRDCRN

APP FNC APP INT APP PRD

D1 D2 D3

File System Source D1 D1 PC1

Integration /AcceptanceCorrection

IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

Figure 1. Supported Promotion States and Technology Layers

Content Focused Roles • Application Developer /Functional Expert (Business Analyst)

Responsible for the definition and development of the functional elements within the application. The Functional Expert works with the conceptual (or logical) definitions while the Application Developer works with the implemented (or physical) definitions.

• Expert User Responsible for providing content and functionality information to the other roles. Also responsible for test scenarios and corresponding test data.

• Functional Architect (or Lead Developer) Responsible for providing functional element standards guidance and enforcement including approval of elements for promotion.

• Team Lead Responsible for facilitating element development and review, as well as element standards enforcement and element promotion. This role is primarily one of project management and control rather than element creation or content control.


• Application Architect Responsible for approving and controlling functional element definitions across multiple projects. This includes the creation and dissemination of functional element definition standards and guidelines.

• Functional DBA Responsible for data focused elements and as such serves as a liaison between the functional element focused roles, the Data Architect role, and the Database Architect role. Also is the point of first contact with regard to functional, data access, and data structure performance tuning.

• Data Architect Responsible for approving and controlling data element definitions at both the conceptual and physical level.

• Database Architect (or Enterprise DBA) Focused on the implementation of the application’s data elements including schema and storage parameter definition.

• Promotion Administrator Focused on the actual promotion of elements through the Integration Testing environment and into Production. The role also enacts all physical aspects of application software release assembly.

Environment Focused Roles • Configuration Manager

Responsible for defining the controls for versions of containers and of structured (Designer based) and unstructured (file based) elements. This role also controls the assembly of the element versions into recognized groups for promotion or release management purposes.

• Repository Manager Responsible for the integrity and usage of the overall Designer Repository, including the maintenance of repository users and their overall privileges.

• Generation Framework Administrator Responsible for the customization of elements underlying the generation of forms and reports and other application elements.

• Technical Architect Responsible for identifying and defining the underlying technical architecture across all development projects, including the dissemination of toolset usage standards and guidelines.

• System Manager Responsible for the management of the disk space and servers underlying the development and deployment environments as well as performing server performance tuning.


• Repository DBA Responsible for the management of the database underlying the Designer Repository, including managing space allocation and performance.

Config Mgr

Repos Mgr

Promo Admin

System Mgr

Data Architect

Gen Frmwk Admin

ApplicationArchitect

Team Lead

Functional Architect

Functional DBA

Appln Develope

FunctionalExpert

Repos DBA

Enterprise

Transition

Project

DatabaseArchitect

Technical Architect

Expert User

Figure 2. Application Development Environment Roles

EXAMPLE SCENARIOS The following are example configuration management scenarios (or “Use Cases”) for a representative software development environment. These scenarios describe the promotion states for both successful promotion and unsuccessful rejection from an existing state. They describe the promotion path and the types of elements promoted, the mechanisms in use for the promotion, and the roles involved in the promotion.


Conduct Development Activity in a Team Development Environment Establish a development environment for the entire team to conduct development activities. This is the default style of development environment in which changes made to an application element are visible to all other team members.



J:\app\fnctst\ -fmb

-mmb -sql -ddl


Tools


APP_RET



Production Correction

Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST

Integration / Acceptance

Test

J:\app\inttst\ -fmb

-mmb -sql -ddl


APP_RET

-ddl

APP_PRDCRN


D1 D2 D3


Integration / Acceptance Correction

IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

Initiate Development

The Configuration Manager creates and enables access to a Development Workarea. This workarea includes the appropriate containers and elements.

The Team Leader manually assigns responsibility for elements to specific team members based on dependency analysis and requirements. Element Check Out/In is employed for element versioning, but does not restrict team members from accessing changed elements. Versioning is not usually used during the initial requirements definition and analysis phases of development.

Team members share a single Development Database (as they share a workarea). It is possible, but not recommended (due to file locking issues) to share a network Development Directory. Therefore developers will make use of individual directories as appropriate. Downloading files from the Designer Repository initializes development directories. Team members conduct unit testing against the elements.

Conclude Development

Team members identify elements for requirements approval. The elements are submitted to the Architects for standards approval.

File elements are uploaded to the Designer Repository for retention. Elements that were checked out are checked in to the Main branch as part of the approval cycle.

Conduct Development Activity in a Personal Development Environment



J:\app\fnctst\ -fmb

-mmb -sql -ddl


Tools


APP_RET




Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST


Test

J:\app\inttst\ -fmb

-mmb -sql -ddl


APP_RET

-ddl

APP_PRDCRN


D1 D2 D3



IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

Establish a development environment for a single developer so they may conduct development activities. This is a restricted development environment that segregates changes to an application element away from other team members.

Initiate Restricted Development

The Configuration Manager creates and enables access to a Personal Workarea. This workarea includes the appropriate containers and elements through either Container Inclusion or Configuration rules. If based on Configuration rules, the developers can manage their own workarea(s). Personal Development may use specific branches for Check In, or the Main branch. This depends on the nature of the change and the development life cycle phase.

The Team Leader manually assigns responsibility for elements to a specific team member based on dependency analysis and requirements. Element Check Out is employed for element versioning to restrict other team members from accessing changed elements.


The developer is responsible for establishing a Personal Database based on the Development Database. They make use of individual directories. Downloading and/or checking out files from the Designer Repository initialize these directories. The developer conducts unit testing against the elements.

Conclude Restricted Development

The developer submits the elements for requirements approval and to the Architects for standards approval.

File elements are uploaded to the Designer Repository for retention. Elements are checked in to the appropriate branch (Main or specific) as part of the approval cycle. The Development Workarea must be refreshed after element check in. The Configuration Manager and the developer then remove the Personal Workarea, Database, and Directories.

Promote From Development to System Testing



J:\app\fnctst\ -fmb

-mmb -sql -ddl


Tools


APP_RET




Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST


Test

J:\app\inttst\ -fmb

-mmb -sql -ddl


APP_RET

-ddl

APP_PRDCRN


D1 D2 D3



IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

Establish the testing environment and conduct system, or functional, testing. Testing is conducted on elements within the application against established test cases.

Initiate System Test Environment

The Configuration Manager creates and enables access to a System Test Workarea. This workarea includes the appropriate containers and elements. The System Test Database is established and initialized appropriately by the Functional DBA. The System Test Source and Deployment Directories are established and initialized appropriately by the Functional Architect.

Verify System Test Candidates

The Team Leader verifies that all approvals and unit testing have been completed for the candidate elements. They ensure all documentation, help information, data migration scripts, and other related elements are approved and checked in as well. A list of the candidate elements is maintained using either a Configuration or a User Defined Set (UDS), depending on requirements. A Configuration provides excellent control but requires greater authority, while a UDS is a simple element but with less formal control.

Conduct System Test

All elements to be tested are generated or extracted from the Designer Repository into the System Test Source Directories. They are applied against the System Test Database or compiled into the System Test Deployment Directories as appropriate. The resulting application system is then tested. Elements that pass testing are identified in another UDS. Elements that fail are returned to Development for correction and are removed from the System Test Source Directories and UDS. A backup of the System Test Source Directories is made after each extraction cycle.


Promote From System Testing to Acceptance Testing



J:\app\fnctst\ -fmb

-mmb -sql -ddl


Tools


APP_RET




Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST


Test

J:\app\inttst\ -fmb

-mmb -sql -ddl


APP_RET

-ddl

APP_PRDCRN


D1 D2 D3



IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

Establish the testing environment and conduct acceptance, or integration, testing. Testing is conducted across application systems by Expert Users.

Verify Acceptance Test Candidates

The Promotion Administrator verifies that all approvals have been completed for the candidate elements identified in the System Test UDS. They verify that the UDS contents match the System Test Source Directories contents. They create an Acceptance Test Configuration that lists all of these elements. It should include the release number in the configuration name.

Initiate Acceptance Test Environment

The Configuration Manager creates and enables access to an Acceptance Test Workarea. This workarea is based on the Acceptance Test Configuration and possibly existing Production Configuration(s). The Acceptance Test Database is established and initialized appropriately by the Enterprise DBA. The Acceptance Test Source and Deployment Directories are established and initialized appropriately by the Promotion Administrator. The appropriate inclusion or exclusion of dependent elements from the Acceptance Test Workarea is verified.

Conduct Acceptance Test

All elements to be tested are copied from the System Test Source backup to the Acceptance Test Source Directories. They are applied against the Acceptance Test Database or compiled into the Acceptance Test Deployment Directories as appropriate. The Source and Deployment Directories are backed up. The resulting application system is then tested. Elements that pass testing are identified. This is done so as to simulate the Production Deployment actions as closely as possible.

Reject Elements from Acceptance Test

Elements that fail are usually returned to Development for correction but may be processed through the Acceptance Test Correction cycle. This is done only if the element has undergone changes in Development that must not be promoted to Acceptance Test.

If they are returned to Development, they are removed from the Acceptance Test Source Directories and Configuration. A backup of the Acceptance Test Source Directories is made after removing rejected elements.



J:\app\fnctst\ -fmb

-mmb -sql -ddl


Tools


APP_RET




Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST


Test

J:\app\inttst\ -fmb

-mmb -sql -ddl


APP_RET

-ddl

APP_PRDCRN


D1 D2 D3



IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

Conduct Acceptance Test Corrections Establish an environment for a single developer so they may correct acceptance test state elements. This is a restricted development environment that segregates changes to an application element. It uses branches to allow parallel development.


Initiate Test Correction Environment

The Configuration Manager clones the Acceptance Test Workarea as a Test Correction Workarea and enables access. They create a Test Correction NN Branch (a new one for each correction cycle) and add it as the Default Branch for the workarea, which adds a Latest on Branch rule to the workarea.

The Team Leader manually assigns responsibility for correcting elements to a specific team member based on dependency analysis and requirements. Element Check Out is employed for element versioning.

The developer is responsible for establishing a Personal Database based on the Acceptance Test Database. They make use of individual file directories that are initialized by downloading and/or checking files out of the Designer Repository. The developer conducts unit testing against the corrected elements.

Verify Corrections Complete


File elements are uploaded to the Designer Repository for retention. Elements are checked in to the Test Correction NN branch as part of the approval cycle.

Promote Corrections to Acceptance Test

All corrected elements are generated or extracted from the Designer Repository by the Promotion Administrator into the Acceptance Test Source Directories. They are applied against the Acceptance Test Database or compiled into the Acceptance Test Deployment Directories as appropriate.

A new Acceptance Test Configuration version is created with the corrected element versions. A new backup is made of the Acceptance Test Directories. The Acceptance Test Workarea must be updated to the new configuration version.

The corrected elements are then re-tested. If they fail, they return to the Acceptance Test Correction cycle.

Collapse Test Correction Environment and Merge Result

The Team Leader responsible for the Development version of the corrected elements merges the Acceptance Test Correction element versions back into the Main Branch Development versions when feasible to do so.

The Configuration Manager and the developer remove the Test Correction Workarea, Database, and Directories.


Instantiate Training Environment



J:\app\fnctst\ -fmb

-mmb -sql -ddl


Tools


APP_RET




Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST


Test

J:\app\inttst\ -fmb

-mmb -sql -ddl


APP_RET

-ddl

APP_PRDCRN


D1 D2 D3



IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

Establish the training environment and conduct training activities.

Initiate Training Environment

The Promotion Administrator identifies the Workarea and Deployment Directories that the Training Environment should be based on (usually Acceptance Test). The Training Database is established and initialized appropriately by the Enterprise DBA. The Training Directories are established and initialized appropriately by the Promotion Administrator.

Conduct Training

All elements for training are copied from the appropriate Deployment directories to the Training Directories. The Training Database is initialized from scripts and/or data extracts as appropriate and then backed up for inter-class refresh purposes. The resulting application system is then used for training.

Finalize Acceptance Test for Deployment



J:\app\fnctst\ -fmb

-mmb -sql -ddl


Tools


APP_RET




Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST


Test

J:\app\inttst\ -fmb

-mmb -sql -ddl


APP_RET

-ddl

APP_PRDCRN


D1 D2 D3



IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

The Acceptance Test scenario may be repeated multiple times, based on the need for integration testing, user driven testing, and/or deployment simulation. In each case, the candidate elements may be approved and move on or may be rejected and removed from the Acceptance Test environment.

There are three possible outcomes from Acceptance Testing. They are:

• Everything passes The result is that the Acceptance Test Configuration is consistent with the Acceptance Test Directories backup content. The element set is complete and correct and can be promoted to the Production environment.

• Minor rejections The rejected elements are removed from the Acceptance Test Configuration and the Acceptance Test Workarea is refreshed. They are removed from the Acceptance Test Directories and the backup is re-done. The resulting element set can be safely promoted to Production.

• Major rejections The rejected elements are removed from the Acceptance Test Configuration and the Acceptance Test Workarea is refreshed. The Acceptance Test environment is dropped and instantiated again from the start. This starts another cycle of Acceptance Testing. This extra round of testing is conducted to whatever depth and breadth is deemed appropriate.


Promote From Acceptance Test to Production



J:\app\fnctst\ -fmb

-mmb -sql -ddl


Tools


APP_RET




Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST


Test

J:\app\inttst\ -fmb

-mmb -sql -ddl


APP_RET

-ddl

APP_PRDCRN


D1 D2 D3



IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

Deployment of elements to the production environment, complete with a back-out plan and defined deployment acceptance criteria.

Deployment Preparation

Define the back-out procedures, which will include backup of database content and structures, application executable directories, and other components or directories

Define acceptance criteria for deployment. This includes mechanisms to test deployment, assignments for approval execution, and authority for approval

Create Production Staging Area directories and populate with Acceptance Test Deployment files and database focused Source scripts. Clone the Acceptance Test Configuration as a Production Configuration. It should include the release number in the configuration name.

Freeze the Production environment and create Retirement copies of the Production Database and Deployment Directories.

Production Deployment

Create the back-out copies. Copy in/apply the elements from the Staging Area to the Production Database and Deployment Directories.

Create or update the Production Workarea to include the new Production Configuration as the basis for the workarea.

Perform the acceptance tests and approve or back out the deployment. Perform a full backup of the environment after approval.

Conduct Production Corrections



J:\app\fnctst\ -fmb

-mmb -sql -ddl


Tools


APP_RET




Retirement

D1 D2

D3

D1 D2 D3

APP DEV

Database

File system Appln

C:\app\prdcrn\

-fmb -mmb

-sql

-ddl

APP PCN

C:\app\dev\

Production

APP_INTTST


Test

J:\app\inttst\ -fmb

-mmb -sql -ddl


APP_RET

-ddl

APP_PRDCRN


D1 D2 D3



IC1

APP ICN

APP_INTCRN

C:\app\intcrn\

-fmb -mmb

-sql

-ddl

Establish environment for a single developer so they may correct production state elements. This is a restricted development environment that segregates changes to an application element. It uses branches to allow parallel development.

Initiate Production Correction Environment

The Configuration Manager clones the Production Workarea as a Production Correction Workarea and enables access. They create a Production Correction NN Branch (a new one for each correction cycle) and add it as the Default Branch for the workarea, which adds a Latest on Branch rule to the workarea.

The Team Leader manually assigns responsibility for correcting elements to a specific team member based on dependency analysis and requirements. Element Check Out is employed for element versioning.

The Enterprise DBA is responsible for establishing a Production Correction Database based on the Production Database. The developer makes use of individual file directories that are initialized by downloading and/or checking files


out of the Designer Repository. The developer conducts unit testing against the corrected elements.

Verify Corrections Complete


File elements are uploaded to the Designer Repository for retention. Elements are checked in to the Production Correction NN branch as part of the approval cycle.

The Enterprise DBA refreshes the Production Correction Database.

Test Production Corrections

All corrected elements are generated or extracted from the Designer Repository by the Promotion Administrator into Production Correction Source Directories. They are applied against the Production Correction Database or compiled into Production Correction Deployment Directories as appropriate.

A new Production Correction Configuration is created with the corrected elements. It should include the patch release number in the configuration name. A backup is made of the Production Correction Directories.

The corrected elements are then re-tested.

• If they fail, they return to the Production Correction cycle.

• If they pass, they are implemented into Production using the normal procedures (refer to Promote from Acceptance Test to Production scenario), but using the Production Correction Configuration and Directories as the source (instead of the Acceptance Test ones).

Collapse Production Correction Environment and Merge Result

The Team Leader responsible for the Development version of the corrected elements merges the Production Correction element versions back into the Main Branch Development versions when feasible to do so.

The Configuration Manager and Enterprise DBA remove the Production Correction Workarea, Database, and Directories.

CONCLUSION The scenarios, or “use cases”, given here describe the configuration management practices that you could use for a “typical” software development environment. They show in general terms how, when, why, and by whom a set of software elements are instantiated as a specific promotion state and then correspondingly how and when they move to their next state(s). The configuration management procedures and mechanisms identified are based on the capabilities of the Oracle9i Designer Repository.


These scenarios should assist organizations in developing their own unique configuration management practices. They provide an initial base point as organizations iteratively define and try out procedures in their environment.

Configuration management procedures for any specific environment are primarily impacted by the promotion states supported. Roles and responsibilities identified are constrained by the available staff, skills, and management structures. The mechanisms described here are affected by the depth and breadth of use of the Designer Repository tools.

It is recommended that an organization document the assumptions underlying their configuration management practices as they develop and implement them. This enables the organization to review them as corporate requirements and tool functionality changes.


An Example of Using the Oracle9i Designer Repository for Software Configuration Management July 2002 Author: Robert Gauf Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Oracle is a registered trademark of Oracle Corporation. Various product and service names referenced herein may be trademarks of Oracle Corporation. All other product and service names mentioned may be trademarks of their respective owners. Copyright © 2002 Oracle Corporation All rights reserved.

Date post:	16-Mar-2020
Category:	Documents
Upload:	others
View:	15 times
Download:	0 times

An Example of Using the Oracle9i Designer Repository for … · functional, data access, and data...

Documents