Oracle Designer SCM Guide - British Columbia · Web viewMinistry of Community Services Ministry of Tourism, Sport and the Arts (CS/TSA) Table of Contents 1 Version Control 4 2 INTRODUCTION

Oracle Designer SCM Guide

Ministry of Community Services

Ministry of Tourism, Sport and the Arts

(CS/TSA)

Table of Contents1 Version Control..........................................................................................42 INTRODUCTION.........................................................................................52.1 Audience..........................................................................................................................52.2 Purpose...........................................................................................................................52.3 Assumptions....................................................................................................................62.4 SCM Vendor meeting prior to project commencement....................................................62.5 Other Documents.............................................................................................................6

3 Configuration Management - background..............................................63.1 What is Configuration Management................................................................................63.2 Software Configuration Management (SCM)...................................................................7

4 DEFINITION OF TERMS.............................................................................74.1 Element........................................................................................................................... 74.2 Version tree.....................................................................................................................74.3 Container.........................................................................................................................84.4 File Folder Structures......................................................................................................8

4.4.1 Database files (DDL/DML) Scripting Standards..........................................................104.5 Workarea.......................................................................................................................114.6 Configuration.................................................................................................................114.7 Promotion model............................................................................................................11

5 Repository–wide policies........................................................................125.1 Versioning policies.........................................................................................................12

5.1.1 Automatic branching....................................................................................................125.1.2 Automatic version labeling..........................................................................................145.1.3 Strict locking................................................................................................................14

5.2 Names of files and folders.............................................................................................145.2.1 Case sensitive uniqueness checking...........................................................................14

5.3 Dependencies................................................................................................................145.3.1 Copy on versioning......................................................................................................155.3.2 Copy on copying.........................................................................................................15

6 Security....................................................................................................156.1 Database.......................................................................................................................156.2 Repository......................................................................................................................156.3 Roles............................................................................................................................. 176.4 Workareas.....................................................................................................................176.5 Containers.....................................................................................................................186.6 Configurations................................................................................................................19

7 Seeding of applications with Enterprise standards.............................197.1 What gets seeded..........................................................................................................197.2 Seeding workarea..........................................................................................................207.3 The seeding process.....................................................................................................20

7.3.1 Seeding an empty container........................................................................................217.3.2 Seeding an existing container for the first time............................................................237.3.3 Adding new seed domains to a previously seeded container......................................257.3.4 Upgrading previously seeded domains.......................................................................287.3.5 Copying seed domains................................................................................................30

7.4 Verifying updates to seeded elements...........................................................................32

8 PROMOTION MODELS............................................................................338.1 Development Promotion model.....................................................................................338.2 Parallel maintenance promotion model..........................................................................358.3 Emergency fix promotion model....................................................................................378.4 Promotion management procedures.............................................................................39

8.4.1 Overview..................................................................................................................... 408.4.2 Delivery.......................................................................................................................418.4.3 Release Build and Promotion......................................................................................538.4.4 Pre-Configuration QA Checks.....................................................................................708.4.5 Post-Configuration QA Checks (WA_DELIVERY_<APP>).........................................738.4.6 Promotion from WA_TEST_QA to WA_PRODUCTION..............................................758.4.7 Demotion..................................................................................................................... 778.4.8 Non-release-based (exception) configurations............................................................778.4.9 Transfer of Application Version...................................................................................788.4.10 Transfer of Entire Application......................................................................................798.4.11 Archive of Application Version.....................................................................................798.4.12 Archive of Entire Application.......................................................................................79

8.5 Workarea Rules used during Delivery...........................................................................808.5.1 Inclusion Rules............................................................................................................808.5.2 Exclusion rules (optional)............................................................................................80

8.6 Workarea rules used for parallel maintenance..............................................................818.7 Workarea rules used for emergency fixes.....................................................................818.8 Merging..........................................................................................................................81

8.8.1 General (read this first)................................................................................................818.8.2 Container merges........................................................................................................838.8.3 Element merges..........................................................................................................89

9 RELEASE MANAGEMENT.......................................................................939.1 Versioning of base release or patch configuration.........................................................93

10 ADDITIONAL REPOSITORY ENVIRONMENTS......................................9311 CONCLUSION...........................................................................................93


1 Version ControlVer. Description Date Author Org.0.1 First Draft 2003-NOV-10 Scott Petersen SBD0.2 Revised based on feedback 2002-DEC-18 Scott Petersen SBD1.0 Bea’s feedback 2003-JAN-14 Gary Wong SBD1.1 Revised Promotion Model 2004-MAR-12 Gary Wong SBD

1.2 Added Configuration QA Checks (6.2.7, 6.2.8) and WA_TEST_QA to WA_PRODUCTION promotion (6.2.9) 2004-APR-22 Gary Wong SBD

1.3 Renamed WA_DELIVERY to WA_DELIVERY_<APP> conventions 2004-MAY-14 Gary Wong SBD1.4 Added section 6.3 (Workarea Rules) 2004-MAY-18 Gary Wong SBD

1.5 Updated Section 6.2.2 to exclude UDS PAC element from UDS membership 2004-JUNE-1 Rob Gretchen CS

1.6 Included sections on creating a configuration, use of the staging workarea, further explanation on choice of folder version when using INCLUDE_FOLDER_VERSION. Also added QA check on Delivery procedure for container and contents check-in state and use of INCLUDE_FOLDER rule when creating a full release 2004-JULY-19 Bia Stratton BSC

1.7 Added WA_DELIVERY_<APP>_STAGE descriptions and renamed document to “Oracle Designer SCM Guide” 2004-JULY-30 Rob Gretchen CAWS

1.8 Changes relative to allowing concurrent development (emergency fixes and parallel maintenance). Included section on branches, policies, new workareas and merging 2004-AUG-24 Bia Stratton BSC

1.9 Changes based on last review meeting on parallel development and emergency fix environments. 2004-SEP-30 Bia Stratton BSC

1.10 Added mention of meeting prior to project start, for SCM discussion.Added section on inclusion of entire folder hierarchy when creating configuration from workarea spec. 2004-NOV-12 Bia Stratton BSC

1.11 Added section on seeding of application containers from Enterprise model standards.Added section on new workarea rule for parent folder inclusion for all files in UDS. 2004-DEC-6 Bia Stratton BSC

1.11 New workarea for prevention of check-outs of seeded elements. Few changes to seeding process to account for usage of this workarea 2005-MAR-15 Bia Stratton BSC

1.12 Removed usage of INCLUDE_FOLDER during release deliveries 2005-MAR-21 Bia Stratton BSC1.13 Make use of delivery staging workarea mandatory and use this workarea for

configuration build. Also, added new post-configuration QA check. 2005-MAY-26 Bia Stratton BSC1.14 Update to reflect change to Ministry name(s) and update wording to reflect

upgrade from Oracle Designer 6i to 10g. 2006-FEB-03Rob Gretchen / Maureen Bird CS

1.15 Update to reflect inconsistencies in “Configuration” creation processes and to focus on only using WA_DELIVERY rules for configurations (Section 8.4.3). Also updates for scripting standards for database deliveries in SQL*Plus (Section 4.4.1) 2006-JUL-26 Rob Gretchen CS

Oracle Designer SCM GuideTue, May 16, 2023 Version 1.14 Page: 4


2 INTRODUCTION This document details the methods of using the Designer 10g repository for version control of software and metadata. This version control, also called Software Configuration Management (SCM) and is a vitally important component of the application development lifecycle. It allows for the structured assembly of application database artifacts (objects) within a configuration management discipline, thus ensuring accuracy and traceability of application releases.

2.1 AudienceThe intended audience for this document includes:

Repository managers who administer the ministry repository

Vendors engaging in systems development and maintenance projects with the ministry

Application support staff involved in installation of applications, evaluation of bugs and enhancement requests

In-house data administration analysts who define standard constructs that are (re-)used by application systems

Business analysts who develop preliminary application models and provide guidance to their clients regarding application development projects

The following table outlines the specific “focus” areas of this document for the varying audience involved with developing applications using the CS SCM processes. This table only provides references for those roles which have “hands-on” requirements for interacting with the SCM process through Designer:

ROLE MANDATORY SECTIONS RECOMMENDED SECTIONS

Repository Manager ALL ALL

Developer (Programmer) Section 8.4 Sections 2-6

Developer (Application Configuration Manager)

Section 8.4, 8.5 ( Sections 2-6

2.2 PurposeThe purpose of this document is to inform the reader about the structure of work environments within the Designer 10g repository, and how application systems releases are managed, within this set of environments.



2.3 Assumptions Versioning of the repository is enabled

The Ministry will be responsible for all backups of the container; at any time, Ministry staff can see the work in progress

Labeling of the releases shall be via Configurations; the container ‘version’ will not be used to identify releases

Non-Oracle code (e.g. .java class files.) will not be included in the repository but will be included in the Ministry VSS implementation or on the Ministry network.

Documentation in the form of Word Documents etc. will be included in the repository.

Repository users that have read or write access will connect to the repository via named individual accounts (e.g. case_jsmith )

Individual accounts will have only the minimum access rights and privileges to do their job (e.g. see only the applications and workareas for which they’re responsible)

Throughout the remainder of the document, the Ministry of Community Services and the Ministry of Tourism, Sport and the Arts shall be referred to as “the Ministry”.

2.4 SCM Vendor meeting prior to project commencementIt is important that the project team and business analysts meet with the Ministry repository manager prior to project start, to discuss how the use of software configuration management practices will affect the project activities and schedule.

Project teams should be familiar with SCM standards and their responsibilities in the area of version control and release management and delivery. This introductory meeting will provide an overview of Ministry SCM practices, expectations and services provided.

2.5 Other Documents Oracle Designer 10g Standards and Guidelines

3 Configuration Management - background

3.1 What is Configuration ManagementConfiguration Management is the discipline of organizing and managing products and their individually existing component parts. The right components need to be assembled in the right way to produce the appropriate end product.

Components can be altered slightly or recombined to create a slightly different version of the end product (or a different product altogether). One of the goals of Configuration Management (CM) is to manage the processes by which new component versions are created and their variations documented.



It also addresses the recording and creation of new end products, particularly which component versions are involved in assembling the product.

3.2 Software Configuration Management (SCM) Configuration management applies to software engineering since the software products are usually made of a selection of components.

An individual program, or a database table, is usually a component of a specific application. An application requires a specific combination of versions of these components in order to function as a whole. In addition, a suite of applications or the applications that combined make up the enterprise environment also needs to be ‘version aware’ of each other.

While historically the information systems industry has done reasonably well in managing elements at the file level and database level, it is only recently that the IT professionals have been faced with the need to manage meta-layer elements. With the use of CASE (Computer Aided Systems Engineering) tools, a new level of complexity was added to the CM discipline. The analysis and design definitions, which originate an application’s physical components, also need to be configuration managed.

4 DEFINITION OF TERMS

4.1 ElementAt the lowest level of granularity, the Repository is filled with elements (also referred to as objects; the two terms are interchangeable). All elements are classified as either Structured or Unstructured.

structured element - A structured element is an element whose internal structure (secondary elements, references and properties) is fully known to and understood by the Repository infrastructure. The main categories of Structured Elements at this moment are the Oracle Designer element types (Entity, Business Function, Table Definition etc.)

unstructured element - An element that has a structure that is unknown to the Repository infrastructure is, somewhat strongly, labeled Unstructured Element. This term does not claim such elements are in fact without internal structure, it merely states that the Repository is unaware of that structure and therefore can only handle the element as a whole.

4.2 Version treeConfiguration Management makes use of tree structures to maintain the evolution of elements into their various versions. Maintaining snapshots would be of little use if the sequence of their occurrence were unknown. Versions are nodes in a tree, and the linkage between a version and its predecessor is known information.

Version trees have a main branch and any number of branches. Branches can stem from the main branch or from another branch, and can also be combined or merged together into a single branch. The figure below illustrates a typical element version tree.



MAIN EMERGENCY FIX

1.0

1.1

1.0.3.1

1.0.3.2

PARALLEL MAINTENANCE

1.0.2.2

MAIN

1.0

1.1

1.1.1.0

1.1.1.11.2.1.0

1.11.2

1.11.3

merge

MAIN EMERGENCY FIX

1.0

1.1

1.0.3.1

1.0.3.2

PARALLEL MAINTENANCE

1.0.2.2

MAIN

1.0

1.1

1.1.1.0

1.1.1.11.2.1.0

1.11.2

1.11.3

merge

4.3 ContainerA container is an object that groups elements within the repository. Containers have the version dimension built-in. In other words, containers hold all versions of every element they own. The same container always owns all versions of a repository element.

Containers can contain other containers in a hierarchical fashion.

Containers can be of two types:

Folder - a container that holds unstructured elements

Application System - a container that holds structured and possibly unstructured elements

4.4 File Folder StructuresThe Ministry standard folder structure for non-generated items, such as DDL/DML scripts, release

documents which are created outside of Designer but need to be included in release management activities is:CM_non_generatedCM_non_generated\adminCM_non_generated\dataconvCM_non_generated\db_objectsCM_non_generated\docCM_non_generated\installCM_non_generated\non_db_sourceCM_non_generated\wwwCM_non_generated\db_objects\schema foldersCM_non_generated\db_objects\schema_app foldersCM_non_generated\db_objects\schema_case foldersCM_non_generated\db_objects\schema folders\IndexesCM_non_generated\db_objects\schema folders\SequencesCM_non_generated\db_objects\schema folders\Synonyms



CM_non_generated\db_objects\schema folders\TablesCM_non_generated\db_objects\schema folders\TriggersCM_non_generated\db_objects\schema folders\ViewsCM_non_generated\db_objects\schema_app folders\FunctionsCM_non_generated\db_objects\schema_app folders\JavascriptsCM_non_generated\db_objects\schema_app folders\Package bodiesCM_non_generated\db_objects\schema_app folders\PackagesCM_non_generated\db_objects\schema_app folders\ProceduresCM_non_generated\db_objects\schema_app folders\Type bodiesCM_non_generated\db_objects\schema_app folders\TypesCM_non_generated\db_objects\schema_case folders\FunctionsCM_non_generated\db_objects\schema_case folders\JavascriptsCM_non_generated\db_objects\schema_case folders\Package bodiesCM_non_generated\db_objects\schema_case folders\PackagesCM_non_generated\db_objects\schema_case folders\ProceduresCM_non_generated\db_objects\schema_case folders\Type bodiesCM_non_generated\db_objects\schema_case folders\TypesCM_non_generated\non_db_source\formsCM_non_generated\non_db_source\iconCM_non_generated\non_db_source\javaCM_non_generated\non_db_source\otherCM_non_generated\non_db_source\reportsCM_non_generated\non_db_source\sqlCM_non_generated\www\htmlCM_non_generated\www\iconCM_non_generated\www\img

The Ministry standard folder structure for project deliverables is:CM_project_delivCM_project_deliv\AppDevCM_project_deliv\BusReqDefnCM_project_deliv\ConfMgmtCM_project_deliv\CtrlRepCM_project_deliv\DataConvCM_project_deliv\DBDsgnBldCM_project_deliv\DocCM_project_deliv\ExSysExamCM_project_deliv\ProjMgmtCM_project_deliv\QualMgmtCM_project_deliv\ResMgmtCM_project_deliv\SupportCM_project_deliv\TechArchCM_project_deliv\TestingCM_project_deliv\TrainingCM_project_deliv\TransitionCM_project_deliv\WorkMgmt



Before you can version files in the repository, you have to upload them into the appropriate sub-folder within the application you're working on.

Every application has at least one mandatory sub-folder: "CM_non_generated" and optionally CM_project_deliv", for holding non-generated application components and CDM project deliverables, respectively.

The "CM_non_generated" folder has a number of sub-folders to cater for the typical types of files that applications require. Additional sub-folders can be created by the repository manager if required.

The "CM_project_deliv" folders have a number of sub-folders which correspond to Oracle CDM processes. Project deliverables should be placed in the appropriate folder prior to versioning.

File upload and download are done in the Repository Object Navigator (RON).

To upload a file Navigate to the folder you want the file to be in, and select the file if it already exists. Then select "Upload Files and Folders" (either from the Utilities menu, or from the right-mouse-click menu).

Note: If you're uploading a modified version of a file that is already under version control in the repository, the file should be in check-out state, and you should select the "overwrite changed files" option on upload

To download a file

Select the file. Then select "Download Files and Folders" (either from the Utilities menu, or from the right-mouse-click menu). If you intend to make changes to the file, you should check-out the file as well, to indicate to others that the file is being worked on.

It is possible to upload and download multiple files at a time, by applying the same functions to a group of selected files.

Note: The Ministry standard delivery folder structure may be extended if deemed necessary by the Ministry project team in consultation with the developer.

4.4.1 Database files (DDL/DML) Scripting StandardsIt is expected that any files uploaded into Designer that execute DDL/DML statements be properly formatted and tested prior to delivery (upload) to the ministry’s Designer repository. All DDL/DML files should conform to the following specification:

1) All DDL/DML files MUST be properly formatted and tested to execute in SQL*Plus (10g client version). Those files which do not conform will be immediately returned to the developer.



2) Multiple DDL/DML files that execute as a sequenced set must be invoked from a driver (.sql) file.

3) Output from all DDL/DML files must be logged to the appropriate log file. The log file should have the same name as the SQL file which creates it, except should have the “.lst” extension.

4) The DDL/DML scripts should have some comments at the beginning stating the name of the script file itself, who the author is, what database connection (userid) is required to run the script, and what the body of the script generally does (purpose).

5) DDL and DML statements generally should run independent of each other in their own script files.

6) Any DDL statements which build PL/SQL objects (eg. Package, Package Body, Procedure, Function, Trigger) should include a “SHOW ERROR” command after the DDL statement that creates the object. This will ease troubleshooting when DDL commands abend due to errors, although the expectation is that the scripts have been thoroughly tested by the developer.

4.5 WorkareaA workarea is an environment that provides a ‘version-resolved’ view of specific repository elements for a specific group of users / user role. That is, it shows one version of each of the objects defined in the workarea. These objects may be the latest version of all objects in a container or specific versions based on a configuration.

Access rights are established for work areas. Work areas are usually based on containers and / or configurations, which may have further access rights defined. Thus, the contents of a workarea may vary from user to user, due to their varying access rights to the underlying components.

4.6 ConfigurationA fixed set of element versions. Configurations provide the basis for Release Management. They specify the element versions that together make up a product release or patch.

Configurations themselves can also be versioned.

4.7 Promotion modelA promotion model is the specific set of environments and technology levels that elements go through during their development or maintenance process, as well as the allowed environment transitions.

Promotion level - the development levels that an element goes through. These levels generally follow the adopted systems development life cycle, with some additional levels. An example of a set of promotion levels is:



Development

Delivery

Test_QA

Production

Promotion environment - a physical environment where elements reside during their existence in a promotion level. Each technology layer requires a promotion environment for each promotion level. The designer repository is an example of a Promotion environment.

Promotion - an allowed state transition between promotion levels (e.g. Promotion from Test_QA to Production)

Demotion - an allowed state transition ‘rollback’ between promotion levels (e.g. Demotion from Delivery back to Development)

5 Repository–wide policiesRepository-wide policies dictate repository behaviour when certain tasks are executed by the user. The figure below shows the repository policies currently in use at the Ministry.

5.1 Versioning policiesVersioning policies control tool behaviour on check-in and check-out operations.



5.1.1 Automatic branchingWhen selected, each workarea must have a default check-in branch. This default branch is provided to users in the check-in pop-up window. (Note that users are still able to change the check-in branch. This is not recommended though. It is a shortcoming of the tool)

Branches supported by the repository are used by the Ministry promotion models for parallel maintenance and emergency fix. These branches are called PARALLEL MAINTENANCE and EMERGENCY FIX respectively.

An additional branch called ENTERPRISE SEED is used to store the seeded elements (that were placed in a application container through the seeding process). These seeded elements originate from an Enterprise model.

To verify what elements have branched versions, use the Version Edit branch labels… window. Select the desired branch and click Used by. All elements using the branch will be shown ordered by their owning container, as shown in the two figures below.



5.1.2 Automatic version labelingWhen selected, each new object version is automatically assigned a version label on check-in.

Automatically calculated version labels follow this convention:

1. For versions on the MAIN branch, labels are in the format 1.<99>, where <99> is a number starting in 0 and incremented by 1 at every check-in.

2. For versions on a branch, labels are in the format <source element version label>.1.<99>, where <source element version label>.is the version label of the element that provides the source for the new branch, and <99> is a number starting in 0 and incremented at every check-in

5.1.3 Strict lockingWhen selected, ensures that only one version can be in check-out state per branch.

5.2 Names of files and folders

5.2.1 Case sensitive uniqueness checkingWhen selected, activates case sensitivity checking for the names of new file system files and their containers when these are created in the repository. (Note that there are issues with the enforcement of this policy. The repository appears to be case-sensitive regardless of the setting of the policy.)

5.3 DependenciesThe following options control the default setting for what happens to dependencies for certain operations on repository objects. In either case the default can be overridden at the time of the



operation. Dependencies, in this context, refer to calculated element dependencies available in the dependency Manager tool. These are impact analysis dependencies (as opposed to metadata associations such as entity relationships etc).

5.3.1 Copy on versioningWhen selected, causes object dependencies to be copied by default when a new version of an object is created.

5.3.2 Copy on copyingWhen selected, causes object dependencies to be copied by default when an object is copied.

6 SecuritySecurity in the Designer 10g Repository is controlled at multiple levels. A user must have the appropriate permissions at each of the levels before they are able to use an element in the repository. For example, user “Steve Smith” has an Oracle userid, has been granted permission to use the repository and has the “Select” permission on the LGIS application container. However he does not have any permissions on any of the workareas so is unable to view or interact with the LGIS application. When he is granted, at the very least, “Select” on a workarea of which LGIS is a part, he will be able to interact with the application.

6.1 DatabaseEach user that accesses the repository must have an Oracle userid with the connect privilege. There are currently two distinct classes of users that will use the repository. These classes and the naming convention for each are as follows:

1. Repository owner (which also defaults to application owner for all containers)

2. Named users (anyone who needs read or write access to the repository)CASE_<NAME>e.g. CASE_SSMITH

6.2 RepositoryThe repository manager must grant all users permission to use the repository. This is done using the Repository Administration Utility. In order for the repository manager to grant these permissions, the Oracle userid must already exist.

In order to grant permissions on the repository to the user perform the following steps:

1. Connect to target repository using the Repository Administration Utility

2. Click the Maintain Users button

3. Select “Users”



4. Click the green plus (+) button to add a new user.

5. Select the Oracle userid from the drop list labeled “Oracle User Name”

6. Set the permissions as shown in the following screen shot for regular users

7. Set the permissions as shown in the following screen for those users who are filling the role of the application configuration manager. This role is responsible for assembling and testing the application release content before delivery to the repository manager for actual release creation.



8. Click OK

6.3 RolesThere is one available role in the repository called PUBLIC. Unfortunately, this role is hard-coded in Designer and can’t be altered. As well additional roles cannot be added. However, this role is great for granting permissions to ALL users. The permissions on the different work areas are granted using the PUBLIC role.

In order to grant permissions to public on an object, use the steps in Section 6.4and 6.5

6.4 WorkareasThe next level of access control is the workarea. In order for a user to see or manipulate the objects that are part of a work area they need to have permissions to do so. All users, except for application owners and the repository manager, get permissions for workareas in the Ministry repository from the PUBLIC



role and do not need to be changed for an individual user. The following table outlines the permissions granted on work areas:

Workarea name Application Configuration

Manager

REPOSITORYMANAGER

Public Role

WA_DEVELOPMENT ALL Select, Insert, Update, Delete, Version

WA_DELIVERY_<APP> Update Spec, Compile

ALL Select

WA_DELIVERY_<APP>_STAGE Update Spec,Compile

ALL Select

WA_TEST_QA ALL Select

WA_PRODUCTION ALL SelectWA_PARALLEL_MAINTENANCE

ALL Select, Update, VersionNote: access to this workarea is enabled on request, and disabled after parallel maintenance changes have been merged back into the MAIN branch.

WA_EMERGENCY_FIX ALL Select, Insert, Update, Delete, Version

WA_ARCHIVE ALL Select

WA_ON_HOLD ALL SelectWA_GENERAL_RM_TASKS ALL

WA_ENTERPRISE_SEEDING ALLWA_BLOCK_SEEDED_CHECKOUTS

ALL

6.5 ContainersThe next level of access control is the container. Each user must have permissions on the container before they can perform actions on that container.

In order to grant permissions to users for a container perform the following steps:

1. Connect to the repository using the Repository Object Navigator as the REPOSITORY MANAGER.

2. Open the Repository object. (You will need to go up a level to be able to select “Repository”)

3. Navigate to the container

4. Right click on any container and select “Grant Access Rights”

5. Click the name of the user in the “Users” column



6. Check the needed options in the “To Grant” column. Note: Do not grant “Update Spec”, “Compile” or “Administrate” even if they are availableNote: Generic users should get SELECT access ONLY.

7. Check the “Recurse Sub-Containers” option

8. Click the “Grant” button”

9. Click “OK”

6.6 ConfigurationsThe final level of access control is the configuration. Configurations that represent application releases must be made visible in read-only mode to application configuration managers (who require them for context during delivery workarea setup).

In order to grant permission on the configuration perform the following steps:

1. Connect to the repository using the Repository Object Navigator as the REPOSITORY MANAGER

2. Open the Repository object. (You will need to go up a level to be able to select “Repository”)

3. Expand the Configurations node.

4. Select the configuration you want to grant access to and expand it. You should see the versions that have currently been created for that configuration.

5. Select any version. Right-click and select “Grant Access Rights”.

6. Proceed as usual to grant “Select” only to the designated application configuration manager account.

7 Seeding of applications with Enterprise standards

7.1 What gets seededThe Ministry maintains a set of standard domain definitions for the most commonly used data types.

This set of domains (or a subset of it) provides a starting point for data modelers during system analysis and design.

When new application development projects start, the repository manager and data administrators will establish the set of domains that provides a good starting point to the application. This set of domains is then seeded into the application container.

IMPORTANT NOTE: Seeded elements are not meant to be altered in the application system. Application delivery will fail quality assurance and will not be promoted to production if changes are detected in seeded elements.



Seeding affects the element’s version tree as shown in the figure below. The seed element provides version 1.0 on the MAIN branch, and also version 1.0.1.0 on the ENTERPRISE SEED branch. This branch provides a frozen view of what was originally seeded.

Seeded elements are delivered to the application in checked-in state.

7.2 Seeding workareaThe workareas used during the seeding process are:

Workarea name Description

WA_ENTERPRISE_SEEDING Volatile contents.

This workarea is populated with the Enterprise configuration and is used to create and seed the new application container.

The default check-in branch for this workarea is ENTERPRISE SEED.

WA_BLOCK_SEEDED_CHECKOUTS This workarea contains configurations containing the seeded elements on the MAIN branch, for all seeded containers. It is used to perform a “dummy” check-out of the seeded elements in order to prevent check-out by a developer.

7.3 The seeding processNOTE: An application undergoing seeding should not be changed by developers during the seeding process. If changes are made by a developer, they may be lost in the event of a rollback of the container to a pre-seeded state.



To seed an application container, follow the steps in the appropriate scenario below:

7.3.1 Seeding an empty containerIn this scenario, a new application development project is starting, and you want to seed the application container with a “starter set” of domains from the Enterprise standards.

1. Go to the WA_ENTERPRISE_SEEDING workarea. Ensure that the workarea contains the LATEST(Enterprise Seed) rule followed by the configuration representing the latest version of the “Enterprise domain standards” container. The workarea rules should contain the INCLUDE_CONFIG rule for this configuration.

2. Take note of the configuration name and version as you will need it later in this process.

3. Create the new container

4. Follow the instructions in the ‘Copying seed domains’ section later in this document.

5. Select the application container and all domains and perform a check-in.

a. In the check-in notes, specify the configuration (and its version) that you used to create the elements. For example, your notes could say ‘Seeded from configuration ‘ENTERPRISE DOMAINS release 1.00.00’ version 1.0’.

b. Notice that the result of this check-in is a version tree with version 1.0 on MAIN and 1.0.1.0 on ENTERPRISE SEED. These two versions are identical. Also note that the folder itself is also versioned in the ENTEPRISE SEED branch. The branched folder



version will indicate the seed additions over time whereas the folder version on MAIN will indicate the application element additions.

6. Create a baseline configuration representing the contents of the application after seeding.

a. Name the configuration ‘<App acronym> seed baseline on MAIN’

b. Use the INCLUDE_FOLDER rule with the new application as the folder, on MAIN. NOTE: you have to go to the ‘All Containers’ node to select the container version on MAIN.

c. Check-in the configuration

7. Create another configuration representing the contents of the application on the Enterprise Seed branch.

a. Name the configuration ‘<App acronym> seeded elements on Enterprise Seed’.

b. Use the LATEST_CONFIG_CONTENTS rule, with the configuration created in the previous step, and the Enterprise seed branch.



8. In the WA_BLOCK_SEEDED_CHECKOUTS workarea, edit the workarea to include the ‘<APP acronym> seed baseline on MAIN’ configuration.

9. Check-out all the elements you’ve just seeded (but don’t check-out the container). This is a “dummy” check-out that will prevent unwanted check-outs of seeded elements by application developers.

c. In the check-out notes add “Temporary check-out to prevent further check-out of this version by developers. Check-out will be un-done if this seed version is superseded by a revised version or if the Repository Manager deems necessary for another reason.”

10. Refresh the development workarea to include the new application version.

7.3.2 Seeding an existing container for the first timeIn this scenario, the application already exists, and you want to add standard domains to the application container. The application has never been seeded.

1. Ensure that none of the domains you are seeding already exist in the target container. This is a visual check using the RON and version history viewer.

d. If matching domains exist (they were created by the development team):

i. if you want to overwrite these with enterprise domains, the application domains should be renamed first. Then you may proceed with the seeding process. After seeding, the development team may re-direct the usages of the old domain to the new one.



ii. If by comparing the domains (using the compare tool) with the corresponding domain in the Enterprise container you determine that they are identical and you want to “make them a seed domain”:

1. Carry out steps 2 through 4 to populate the seeding workarea,

2. check-out the domains you want to set as seeded.

e. If no matching domains exist: proceed with the seeding process.

11. Ensure that the entire container and contents are checked-in in WA_DEVELOPMENT.

12. Create a savepoint configuration with the entire container contents (using INCLUDE_FOLDER rule), as a rollback position .

13. Edit the WA_ENTEPRISE_SEEDING workarea:

f. Ensure that the WA_ENTERPRISE_SEEDING workarea contains the configuration representing the latest version of the “Enterprise domain standards” container. The workarea rules should contain the INCLUDE_CONFIG rule for this configuration.

g. Take note of the configuration name and version as you will need it later in this process.

h. Use the INCLUDE_FOLDER rule to include the target container in the workarea.

14. Check-out the target container.

15. Follow steps in the ‘Copying seed domains’ section later in this document.

16. Select the application container and all domains you’ve created or checked-out and perform a check-in.


b. Notice that the result of this check-in is a version tree with version X.Y on MAIN and X.Y.1.0 on ENTERPRISE SEED for all domains that existed in the application and became part of the seeded set. These two versions are identical. Also note that the folder itself is also versioned in the ENTEPRISE SEED branch. The branched folder version will indicate the seed additions over time whereas the folder version on MAIN will indicate the application element additions.

17. Create a configuration representing the contents of the application after seeding, on enterprise seed.

a. Name the configuration ‘<App acronym> seeded elements on Enterprise Seed’

b. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on branch Enterprise seed.




18. Use the merge tool to bring in the new domains to the container version on MAIN. Follow the container merge instructions in this document using the MAIN branch as the target version and the ENTEPRISE SEED branch as the source version.

19. Create a configuration representing the contents of the application after seeding, on the MAIN branch. Name it ‘<APP acronym> seed baseline on MAIN’.

a. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on MAIN.

i. NOTE: you have to go to the ‘All Containers’ node to select the container version on MAIN.

i. Check-in the configuration.

20. In the WA_BLOCK_SEEDED_CHECKOUTS workarea, edit the workarea to include the ‘<APP acronym> seed baseline on MAIN’ configuration created in the previous step.

21. Check-out all the elements you’ve just seeded (but don’t check-out the container). This is a “dummy” check-out that will prevent unwanted check-outs of seeded elements by application developers.

j. In the check-out notes add “Temporary check-out to prevent further check-out of this version by developers. Check-out will be un-done if this seed version is superseded by a revised version or if the Repository Manager deems necessary for another reason.”


7.3.3 Adding new seed domains to a previously seeded containerIn this scenario, the application has already undergone seeding, but you want to bring in additional seed domains.

There is no “domain collision” in this scenario. The new seed domains have no matching domains in the application container (addressed in scenarios 7.3.2 and 7.3.4).

1. Ensure that the entire application container and contents are checked-in in the WA_DEVELOPMENT workarea.

23. Create a savepoint configuration with the entire contents of the application to be seeded, on the MAIN branch.

k. Use the INCLUDE_FOLDER rule and select the latest container version on MAIN.


l. Ensure that the WA_ENTERPRISE_SEEDING workarea contains the configuration representing the latest version of the “Enterprise domain standards” container. The workarea rules should contain the INCLUDE_CONFIG rule for this configuration.

m. Take note of the configuration name and version as you will need it later in this process.

n. Use the INCLUDE_CONFIG rule to include the configuration created in the latest seeding of the container. This configuration is the one with container version and previously seeded domains on branch (as opposed to the baselines on MAIN).



25. Check out the target container

26. Follow steps in the ‘Copying seed domains’ section later in this document.

27. Select the application container and all domains you’ve created and perform a check-in.


b. Notice that the result of this check-in is a version tree with version 1.0 on MAIN and 1.0.1.0 on ENTERPRISE SEED. These two versions are identical. Also note that the folder itself is also versioned in the ENTEPRISE SEED branch. The branched folder version will indicate the seed additions over time whereas the folder version on MAIN will indicate the application element additions.

28. Update the configuration representing the contents of the application after seeding.

a. Check-out the latest version of the ‘<App acronym> seeded elements on Enterprise seed’



b. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on branch Enterprise seed.



29. Use the merge tool to bring in the new domains to the container version on MAIN. Follow the container merge instructions in this document using the MAIN branch as the target version and the ENTEPRISE SEED branch as the source version.




b. Check-in the configuration.

31. In the WA_BLOCK_SEEDED_CHECKOUTS, un-do the check-outs of all elements check-out for the seeded container. Workarea.

32. Edit the workarea to include the ‘<APP acronym> seed baseline on MAIN’ configuration created earlier.



33. Check-out all seeded elements (this includes the ones you’ve just seeded and any other seeds from previous seedings) (but don’t check-out the container). This is a “dummy” check-out that will prevent unwanted check-outs of seeded elements by application developers.

o. In the check-out notes add “Temporary check-out to prevent further check-out of this version by developers. Check-out will be un-done if this seed version is superseded by a revised version or if the Repository Manager deems necessary for another reason.”


7.3.4 Upgrading previously seeded domainsIn this scenario, the data administration group has revised some of the enterprise domains and wishes to propagate the revisions to the applications that have been seeded with the domains.

1. Ensure that the entire application container and contents are checked-in in the WA_DEVELOPMENT workarea.

35. Create a savepoint configuration with the entire contents of the application to be seeded, on the MAIN branch.

p. Use the INCLUDE_FOLDER rule and select the latest container version on MAIN.


q. Ensure that the WA_ENTERPRISE_SEEDING workarea contains the configuration representing the latest version of the “Enterprise domain standards” container. The workarea rules should contain the INCLUDE_CONFIG rule for this configuration.

r. Take note of the configuration name and version as you will need it later in this process.

s. Use the INCLUDE_CONFIG rule to include the configuration created in the latest seeding of the container. This configuration is the one with container version and previously seeded domains on the Enterprise seed branch (as opposed to the baselines on MAIN).

37. Check-out each domain you want to update.

38. Manually edit each domain you want to update.

39. Check-in all edited domains

a. In the check-in notes, specify the configuration (and its version) that you used to create the new versions. For example, your notes could say ‘Re-Seeded from configuration ‘ENTERPRISE DOMAINS release 1.01.00’ version 1.0’.

b. Notice that the result of this check-in is a version tree with an updated branch version X.Y.1.Z on ENTERPRISE SEED.

40. Update the configuration representing the contents of the application after seeding.

a. Check-out the latest version of the ‘<App acronym> seeded elements on Enterprise seed’



b. Use the ‘Refresh all existing members with their latest versions’ option. The new versions on Enterprise seed branch will be picked up.




41. Use the merge tool to bring in the domain changes to the domain version on MAIN. Follow the element merge instructions in this document using the MAIN branch as the target version and the ENTEPRISE SEED branch as the source version.

t. Note that this merge can be done by the developer. Developers know best what the application needs. For example, for a domain with allowable values, a given application may not want all allowable values specified at the enterprise level.




u. Check-in the configuration.

43. In the WA_BLOCK_SEEDED_CHECKOUTS, un-do the check-outs of all elements check-out for the seeded container. Workarea.

44. Edit the workarea to include the ‘<APP acronym> seed baseline on MAIN’ configuration created earlier.

45. Check-out all seeded elements (this includes the ones you’ve just seeded and any other seeds from previous seedings) (but don’t check-out the container). This is a “dummy” check-out that will prevent unwanted check-outs of seeded elements by application developers.

v. In the check-out notes add “Temporary check-out to prevent further check-out of this version by developers. Check-out will be un-done if this seed version is superseded by a revised version or if the Repository Manager deems necessary for another reason.”

46. Refresh the development workarea to include the new domain versions.

7.3.5 Copying seed domains1. In the Enterprise container, select all the domains you want to use for seeding.

47. Select Utilities Extended Copy

48. The follow pop up may appear. (This is faulty behaviour from Designer and may be fixed in future releases. Designer assumes that the source container will become the target container. Since the source container is checked-in, it asks if you want to check it out.)



w. Do NOT check-out, i.e. select No.

49. Click Browse to select the target container. This will be the application you’ve created or included in step 4.

50. Verify that you have all domains to be copied. Then click Next. As there are no referenced objects, click Next again. The wizard will provide you with a list of all copied elements.

51. Click Finish.



52. In the application container, verify that all domains were copied.

7.4 Verifying updates to seeded elementsGenerally speaking, the seeded domains should not require any change during application development. Changes made to these domains should be due to updates to the original seed which are merged into the MAIN version or due to an approved diversion from the seeded standard.

To identify subsequent changes to the original seed, you can use the seed baseline configuration on MAIN to help identify further versions, as follows:

1. Create a new configuration called ‘QA seed updates to <app acronym>.

53. Use the Configurations tab to select the baseline configuration (on MAIN) as the configuration to provide the contents for your new configuration. You are in effect creating a configuration identical to the baseline.

54. Check-in this configuration.

55. Check-out this configuration

56. Edit the configuration. Choose the option ‘Refresh all existing members with their latest versions.

57. You may sort by version label in the configuration members window. Any changed elements will show first with versions other than 1.0.

58. Alternatively, you may save the configuration and then issue a ‘Compare previous version’. The results should show you which elements have new versions.



59. Verify that all elements that have been changed from the seed have been approved by data administrators.

8 PROMOTION MODELSThe Ministry repository supports three promotion models. These cater to application development, parallel maintenance and emergency fix scenarios. The sections that follow detail each promotion model and its supporting environments.

8.1 Development Promotion model This promotion model is used for development of application releases. It can be used for either new application development or maintenance projects where a previous release of the application exists and is being enhanced.

The Ministry repository is set up to provide promotion of applications through various states, from development through to production and archiving. The following diagram outlines the development promotion model.

Work-in-progress development

Development delivery

QA/Test Production

Configuration(s)

promotion

element(s)element(s)Configuration(s)MAIN branchMAIN branch

delivery promotion

On-hold

element(s)

MAIN branch

Archive

archival

Configuration(s)

Application development promotions

transfer

Work-in-progress development


QA/Test Production

Configuration(s)

promotion


delivery promotion

On-hold

element(s)

MAIN branch

Archive

archival

Configuration(s)


transfer

Figure 1: Development Promotion Levels

Application systems produced during systems development and maintenance advance through the horizontal promotion lines until reaching production.

Occasionally, projects may be put on-hold. In these situations, applications will be transferred to a holding area (represented by the “On-hold” box) until the project resumes activities.


WA_DELIVERYWA_DEVELOP WA_TEST_QA

WA_ON_HOLD

WA_PRODUCTION

WA_ARCHIVE


Applications that have reached the end of their useful life will be removed from the production environment, and will be placed in an Archive environment. They will stay in this environment for a period of time and may eventually be removed from the repository and be exported to an archive file.

Following is a description of the application development promotion states:

Development: all development, bug fixes, analysis work, etc, are conducted in this environment. Developers will connect remotely to the repository and use this workarea to modify the repository elements. When an application or application version is ready to be delivered, the elements to be delivered are bundled into a user defined set. The Repository Manager will then be notified via e-mail.

Delivery: this promotion level is where the bundling of elements into releases happens. From here, releases can be promoted to the next promotion levels. This is a mandatory promotion stage.

Quality assurance/test: this promotion level contains elements going through quality reviews. Ministry staff will move the configuration from the Delivery environment to this environment when the application is ready for testing. It is up to each individual project to determine how often this promotion level is populated.

Production: Once the code has been tested and is ready to be put into production, the configuration is moved to this environment at the same time the application is implemented in production. The intent of this environment is to document the current state of the applications that are in production.

Archive: this environment hosts the applications that are no longer in use by the ministry. It provides a temporary staging area before actual archive of the application to an Oracle export file. The objects stored in this environment can either be individual versions of an application, in which case a configuration would be placed here, or an entire application, where the application container would be placed here. An entire application would only be archived if there are going to be no more version of that application.

On-hold: this environment provides a temporary holding area for applications that are put on-hold during a development or maintenance release project. They will stay in this area until the project resumes activities. The objects stored in this environment can either be individual versions of an application, in which case a configuration would be placed here, or an entire application, where the application container would be placed here.

The workareas that represent each promotion level and their description are:


WA_DEVELOP All check-out development and check-in occurs in this work area.

WA_DELIVERY_<APP> Static for presentation of the Production Release of Applications. Dynamically updated as needed with rules such as LATEST_UDS_CONTENTS AND INCLUDE_FOLDER rule.

WA_DELIVERY_<APP>_STAGE Static for presentation of “current” Release of Applications. Dynamically updated as needed with rules such as LATEST_UDS_CONTENTS AND INCLUDE_FOLDER rule



WA_TEST_QA Configuration Based, used Ministry UAT .

WA_PRODUCTION Configuration Based, for the current production version.

WA_ARCHIVE Configuration or container based, for storing old unused, versions of applications

WA_ON_HOLD Configuration or container based, used to store applications that have been put on hold temporarily

WA_GENERAL_RM_TASKS Used by the Repository Manager for various tasks.

8.2 Parallel maintenance promotion modelThe parallel maintenance promotion environments are used when there is a need to proceed with development of a new maintenance release while an earlier maintenance release has not yet reached production.

In general, Ministry projects do NOT require parallel maintenance. This set of environments is therefore available only on request to the Corporate Repository Manager. The environments are disabled by default.

Parallel development of any kind significantly increases complexity of maintaining element versions. This is because it must make use of version tree branches to isolate concurrent versions of an element. These concurrent versions must be addressed at some point in time. You must either determine that a version on a branch has become obsolete and will never be merged to the MAIN development branch, or you must perform a merge. This merge may be either full or selective (where only portions of the branched element are brought back to the MAIN branch). Because of this added complexity, we discourage the practice of parallel development.

Figure 2 shows the parallel maintenance promotion model.



Figure 2: Parallel maintenance promotion levels

The parallel maintenance promotion model shares all but one of its environments with the development promotion model.

Work is done in the Parallel maintenance work space (first box) and gets promoted thorough to production, using the same promotion workareas as the development promotion model. This means that at any given point in time, only one release can be in a state further than its work-in-progress state (development or parallel maintenance). Teams must decide which release gets promoted first.

Please refer to the Development promotion model section for a description of the promotion states following the parallel maintenance state, which is described below.

Parallel maintenance: this environment is used for maintenance of application elements which are awaiting promotion to production from the development work stream. Such elements may not be changed in the development environment because this environment must be available for bug fixing once UAT begins.

The workarea that represents the parallel maintenance environment is:


WA_PARALLEL_MAINTENANCE Changes to elements actively being worked on in the Development promotion environments is done here.

All changes made to elements within this workarea will go to the PARALLEL_MAINTENANCE branch of the


Work -in -progress development


QA/Test Production

Configuration(s)

promotion


delivery promotion

On -hold

element(s)

MAIN branch

Archive

archival

Configuration(s)


transfer

transfer

transfe

r

Parallel maintenance

Development delivery QA/Test Production

Configuration(s)

promotionelement(s)element(s)

Configuration(s)

PARALLEL MAINTENANCE and MAIN branches

PARALLEL MAINTENANCE branch

delivery promotion

On -hold

element(s)

MAIN branch

Archive

archival

Configuration(s)

Parallel maintenance promotions

transfer

transfer

transfe

r

Work -in -progress development


QA/Test Production

Configuration(s)

promotion


delivery promotion

On -hold

element(s)

MAIN branch

Archive

archival

Configuration(s)


transfer

transfer

transfe

r

Parallel maintenance

Development delivery QA/Test Production

Configuration(s)

promotionelement(s)element(s)

Configuration(s)

PARALLEL MAINTENANCE and MAIN branches

PARALLEL MAINTENANCE branch

delivery promotion

On -hold

element(s)

MAIN branch

Archive

archival

Configuration(s)

Parallel maintenance promotions

transfer

transfer

transfe

r


element’s version tree. Therefore they are isolated from the element’s version in the MAIN development branch. The branched changes must be merged to the MAIN branch at the earliest possible time (always after and as soon as the latest version in the MAIN branch has been promoted to Production).

8.3 Emergency fix promotion modelFirst of all, the definition of emergency fix is:

A fix that is made to a production application component showing faulty behaviour which severely hinders the business’s ability to carry out its activities and for which there is no available work-around.

The emergency fix promotion model is available for developers in the event that an emergency fix must be made to a production element that is currently under new development. In this case the development workarea cannot be used as the element version available in the workarea is no longer the version that is in production (and needs the fix). If an emergency fix is required for an element that is currently not being worked on, this fix should be done directly in the development workarea. This avoids having to merge the change back to the MAIN branch afterwards.

Emergency fixes, as the name suggests, need to be done fast. Therefore the promotion model is simplified to the maximum, as seen in the figure below. (The development work space is shown as a reminder that a merge operation must occur to make the changes visible in the development element versions.)



check-in promotion

promotion

LATEST(MAIN)

LATEST(EMERG)

merge

Development

Production

deliverypromotion

Emergency fix

promotion

LATEST(MAIN)

Configuration(s)LATEST(EMERG)

merge

Configuration(s)

element(s)

element(s)

Emergency Fix promotion

check-in promotion

promotion

LATEST(MAIN)

LATEST(EMERG)

merge

Development

Production

deliverypromotion

Emergency fix

promotion

LATEST(MAIN)

Configuration(s)LATEST(EMERG)

merge

Configuration(s)

element(s)

element(s)

Emergency Fix promotion

Emergency fix: this environment allows you to isolate a change to a production element version on a branch called EMERGENCY FIX.

The workarea that represents the emergency fix environment is:


WA_EMERGENCY_FIX Changes to production element versions actively being worked on in the Development promotion environments are done here.

All changes made to elements within this workarea will go to the EMERGENCY FIX branch of the element’s version tree. Therefore they are isolated from the element’s version in the MAIN development branch. The necessity to merge the emergency fix to the MAIN branch should be assessed at the earliest possible time. A merge may not be required, or it may be a selective merge, in cases where the changes being made to the element by new development projects are such that they make the emergency fix no longer applicable (due to functionality changes, re-design, etc).



8.4 Promotion management proceduresThis section describes the promotion management procedures supporting the DMAB promotion model. These procedures are represented in figure 1 by the arrows between the promotion state boxes.

Note: Developers cannot create Configurations, only User Defined Sets (UDS). Ministry staff will

create Configurations based upon the UDS. Configurations are delta based, except for major releases which are full configurations.

The table below summarizes the release creation and promotion procedures, which are further detailed in the sections that follow.



8.4.1 Overview



Procedure Task Responsibility Notes on mechanismsDelivery Create Release User Defined Set Application

Configuration Manager

Use the RON to create a new User Defined Set that contains references to the objects contained in this release.Name the UDS:<APP_NAME>_R01.01.00Where:

APP_NAME is the short name of the app

The numbers, described above, represent:<major release>.<minor release>.<patch upgrade>

Delivery Alert Repository Manager of Release readiness, including request for refresh of DELIVERY database if necessary

Application Configuration Manager

Send e-mail to the Corporate DBA/DA indicating that the release is ready along with the name of the UDS that has been created.

DeliveryCheck UDS for completeness


Perform a quick check on the objects in the UDS to ensure that the correct objects are included.

Delivery Refresh Work Area contents based upon LATEST_UDS_CONTENTS rule


Use the Rules tab of the Edit Work Area Wizard.

Delivery Confirm success of Delivery Application Configuration Manager

Send e-mail to the Corporate DBA/DA indicating that the release is ready to be promoted to TEST_QA

Release build Create Configuration based on UDS

Repository Manager Use the Configuration Wizard in the Repository Object Navigator to select the latest versions of the objects in the UDS created above.Name the configuration:<APP_NAME>_R01.01.00Where:APP_NAME is the short name of the app

The numbers, described above, represent:<major release>.<minor release>.<patch upgrade>

Promotion Promote the application to WA_TEST_QA

Repository Manager Follow steps in section Release Build and Promotion

Promotion Promote the application to Repository Manager Follow steps in section Release



WA_PRODUCTION and WA_DELIVERY_<APP>

Note:<Major release> is for major new functionality (e.g. new components, major rewrites)<Minor release> is for an interim release (e.g. new driver, new small component) that is not a bug fix<Patch upgrade> is a release that specifically addresses one or more bugs.For releases where the major version number changes, ALL objects in the container are to be included. For releases where the major version number does not change, only those objects that have changed are to be included.

8.4.2 DeliveryThe delivery of application releases involves checking-in all changed elements, creating a linkage between these specific application element versions and labeling it with the application release label.

In the Oracle Repository, this task involves:

8.4.2.1 WA_DELIVERY_<APP> DeliveryDelivery of an application to WA_DELIVERY_<APP> involves several steps. The first is to perform basic repository cleanup before the delivery. Developers must remove obsolete element from the container; this includes garbage diagrams and any other deprecated metadata. The importance of this step cannot be overemphasized.

For example, temporary diagrams (e.g. ABC_V1 or XYZ_V2) should be deleted except for the "real one", and the Vx should be removed from this ‘real’ diagram name. There should be no garbage included in Deliveries.

Note that all file uploads should be prefixed with the UDS name (e.g. STVS_R02.00.00_descriptive_text.sql); this includes generated DDL files (e.g. STVS_R02.00.00.tab).

The next step is to ensure that all objects are checked in, as well as the container itself. When delivering a delta release, the UDS should be created correctly, and include all change elements including less obvious ones like revised domains or sequences. This includes the relevant diagrams and related objects (e.g. tables using updated domains or sequences). NOTE: Do not include the UDS PAC element in the UDS membership. This step will be performed by the ministry Repository Manager when the release Configuration is created.

One way to find all related objects is via the “Included In Diagrams” node (for Tables) or “Usages” node (for Domains), or “For Columns” node (for Sequence Definitions).

The delivery code should be tested against the pre-release database environment, and the success of the code changes confirmed.

NOTE: The list of owning folders, for every file object-type, in this release must be included in the Migration Request document (<APP_NAME>_Migration_Request.doc).



Once the container is ready, the Application Configuration Manager should perform the following steps.

In this scenario, the Application Configuration Manager is implementing STVS_R02.00.00, and the UDS does not exist in this workarea prior to this process. The initial state of WA_DEVELOPMENT for: (in this example we are going to be refreshing WA_DELIVERY_STVCMS) STVCMS:



Edit WA_DELIVERY_<APP> workarea using Workarea Wizard. Choose Edit Specification.

The above screen shows the workarea seeded with all the configurations that are in Production.

When delivering a full release, there is no need for the workarea to be pre-populated with previous production releases.

1. Add UDS through LATEST_UDS_CONTENTS rule. Ensure that Branch = Main, correct User Defined Set is selected and after promoting that LATEST_UDS_CONTENTS rule for this UDS is promoted above all other configurations for the workarea.



2. Add a second rule INCLUDE_OBJECT. Browse and include the correct UDS and then promote to Member rules and configurations. Move to top of rule list for clarity

As the right-hand list does not show the entire length of the rule, here is a slightly different screen shot of the exact same dialog (but with the right-hand list scrolled to the right).



3. Use the UDS_MEMBER_PARENT_FDL rule to include the immediate parent folders of all files which are being delivered. You only need to specify this rule once per UDS.

4. As the right-hand list does not show the entire length of the rule, here is a slightly different screen shot of the exact same dialog (but with the right-hand list scrolled to the right.

5. IMPORTANT NOTE:If your UDS contains files, you may have to use the INCLUDE_FOLDER_VERSION, to include the parent folder of each folder that has been newly created and does not exist in the delivery



workarea (due to inclusion of production releases). For example if a new folder was created during the current development/maintenance project, it will not yet be in any production configuration. This means that its immediate parent folder was necessarily versioned to include the new sub-folder. Because the production configuration makes reference to the previous-to-latest version of the parent folder, your new sub-folder will not be visible. You must include the latest version of its parent folder to allow visibility. INCLUDE_FOLDER_VERSION rules must be immediately above UDS_MEMBER_PARENT_FDL rule for this specific delivery (e.g. STVS_R02.00.00).

When all rules have been provided in the Edit Specification window, press OK, then Finish. The workarea wizard will proceed to evaluate the rules provided and populate the workarea. There is no need to preview changes before refresh. Simply choose OK to proceed.



6. Perform a Edit-> Requery All from the menu bar. After the workarea has been refreshed you will see the new UDS, in this example STVS_R02.00.00 in the WA_DELIVERY_<APP> workarea.



If you find issues with the initial UDS and have to reiterate and deliver again, then there are two scenarios:

1. The UDS membership has not changed, but new object versions exist. In this case a workarea refresh of WA_DELIVERY_<APP> is sufficient to include the new version in the workarea.

2. The UDS membership has changed. In this case it is necessary to edit the workarea specification and include the latest version of the UDS using the same process as above.

Don’t forget to remove the previous version of the LATEST_UDS_CONTENTS rule from the Member Rules and Configuration tab.

You must once again ensure that you have all the parent folder versions for all the files in your UDS. If the new UDS version includes new files, you may have to include the file’s parent folder version using one or both UDS_MEMBER_PARENT_FDL and LATEST_FOLDER_VERSION rules.

See the following sections for step-by-step illustrations of both the first (7.4.3, If UDS Membership has not changed) and second (7.4.3, Promotion) scenarios.

8.4.2.2 WA_DELIVERY_<APP>_STAGE extraction workareaNote: This is a mandatory step of delivery.

Each application is given an additional extraction workarea named WA_DELIVERY_<APP>_STAGE. This workarea is for use by the application configuration manager.

The intent of this workarea is to provide a “delta-only” view of the release being delivered, allowing the user to more easily view the release components and extract them to the file system for deployment.

The difference between this workarea and the WA_DELIVERY_<APP> workarea is that the latter provides the full production release context to which the delta release will be applied, where the former provides only the delta itself.

When populating this workarea, you will use the same rules that are used to populate WA_DELIVERY_<APP>. However there is a slight difference in the inclusion of folders, as detailed below.

Initially, the WA_DELIVERY_<APP>_STAGE workarea is empty. There are no inclusion rules in the Member Rules and Configurations box.



To include the delta release members, use the following rules in sequential order (read from bottom to top in the Member rules and configurations list):

LATEST_UDS_CONTENTS: select the User Defined Set you’ve created for this release. This rule will include the latest versions of all elements in the UDS.

INCLUDE_OBJECT: use this rule to include the UDS itself.

UDS_MEMBER_PARENT_FDL; use this rule to include the parent folders of all files in your UDS.

INCLUDE_FOLDER_VERSION: use this rule to include each folder that holds files included in this delivery. Note that you must include each folder in the folder path, from CM_non_generated folder down to the folder that is the grandparent of an included file (parent folder are included by the previous rule).

The figure below shows a typical list of rules used to populate the staging workarea:



Because the Member rules and configurations box does not display the full rule text, the figure below shows the same pop up window with the display scrolled to show the remainder of the rule text.



When all rules have been provided in the Edit Specification window, press OK, then Finish. The workarea wizard will proceed to evaluate the rules provided and populate the workarea. There is no need to preview changes before refresh. Simply choose OK to proceed.

After the refresh is completed, the workarea will be populated with the application container containing only the elements in the release UDS (and the subset of the folder tree required for navigation to files).



This marks the end of the procedures carried out by the application configuration manager role. If you are filling that role you have fulfilled the release management requirements as dictated by the process guide.

Note: After the ministry has prepared and staged a release configuration based on the WA_DELIVERY_<APP>_STAGE workarea there may be deficiencies identified during either the staging process or subsequent IST or UAT testing which require a new delivery by the developer.

In the case where a delivery has failed due to some vendor deficiency, the Work Area will need to be refreshed, based upon the fixes to the UDS. These fixes, done by the Application Configuration Manager, may or may not result in changes to the UDS membership.

If the UDS membership has changed then the Work Area needs to be updated using the LATEST_UDS_CONTENTS, but picking the latest version of the UDS.

If the UDS membership has not changed then a simple refresh of the Work Area is sufficient.



8.4.3 Release Build and Promotion

8.4.3.1 Creating a release configurationThe Configuration Wizard is used to create the set of element versions that make up an application release. You can access this wizard either from the Tools pull-down menu, or by selecting the Configurations node in the RON Navigator pane and clicking the Create Object button on the left vertical toolbar.

Emergency fix configurations contain elements from the EMERGENCY FIX branch. This is the only type of release configuration that can have elements from a branch. This means that elements in the parallel development environment will not be promoted past the delivery stage before the pending release on MAIN is promoted and they are subsequently merged back to the MAIN branch.

The configuration wizard will pop up, as shown in the figure below. Select ‘Create a new configuration’ and provide the required information. The naming convention is as follows:

Configuration name: <APP>_R<Major release>.<Minor release>.<Patch upgrade> where<Major release> is for major new functionality (e.g. new components, major rewrites)<Minor release> is for an interim release (e.g. new driver, new small component) that is not a bug fix<Patch upgrade> is a release that specifically addresses one or more bugs.

Click Next.

You will see a list of options for populating the configuration. The ministry SCM processes only support one method for creating a configuration, and relies on the developer having properly seeded the WA_DELIVERY_<APP>_STAGE workarea. It is important that the Repository Manager perform a



visual QA check on the WA_DELIVERY_<APP>_STAGE workarea prior to attempting to create the release configuration. To proceed with the configuration creation choose:

1. Create configuration from a workarea: this option presumes that the application configuration manager has populated the WA_DELIVERY_<APP>_STAGE workarea with the contents of the release. The population of the WA_DELIVERY_<APP> STAGE workarea is a mandatory step for delivery of the release by the developer. Choose ‘From specification’ to ensure that any subsequent element versions are picked up.

When choosing ‘From specification’,the wizard will go to the Edit Specification window, pre-populated with the rules as in the source workarea. You should review the rules provided. However, there should be no need to add or remove rules because the WA__DELIVERY_<APP>_STAGE workarea rules are exactly the delta that makes up the release, including any folders that may be required to provide the full folder path.

Choose “Next>” to proceed and the next screen dialog will be presented:



At this point no changes are required as the exact Member rules and configurations membership has been populated from the WA_DELIVERY_<APP>_STAGE workarea. Choose “OK” to continue.

The rules specification is shown on the next screen. Chose “Next>” to continue. The following screen will be displayed:



At this stage it is necessary to perform some rudimentary QA on the element listing in this dialog to ensure that the rules are accurate. At this point click on the “Tree” tab and the following view will be shown:



Only the container name and version (eg. GTMS{1.0}) should be visible in this view.

If you see file elements in this listing as per the following screenshot then it will be necessary to remove the individual files using the “Remove Member” function. This situation can occur if the developer packaging the release files has deleted a file with version history from the container and then uploaded another file with the same name. Designer is now version aware of both files as different objects, but the developer isn’t. It is very important the once an object is versioned that it not be deleted and recreated if possible. There is no easy way to move a file level element between folders in Designer and preserve the version history, therefore it is important to keep this in mind when uploading files into the container. A versioned repository is meant to track all changes to an object over its lifecycle and deleting and recreating objects breaks the “version tree” for that object.

In the following example the file “GTMS_R02.00.00_01_system_revoke.sql{1.3}” has been deleted from the GTMS{1.9} container and a file with the same name has been uploaded into the container to start a new version tree “GTMS_R02.00.00_01_system_revoke.sql{1.0}”. The new file will be visible in the appropriate folder if the GTMS{1.9} container hierarchy is expanded and traversed.

After deleting the duplicate files the “Tree” tab listing would appear as follows:



Choose “Next>” to continue with the configuration process. The following dialog is presented.

Simply choose “Next>” again to continue and the next screen dialog will present options for just saving or saving and checking in the configuration. These are important distinctions.



Since this is the initial procedure to create the release config we will choose to “Save and check in configuration” which will create version 1.0 of the release configuration. Choose “Next>” to proceed and the “Check in” screen dialog will be presented.

Fill in the appropriate Check in notes and choose OK to proceed. The last screen presented will confirm that the release configuration has been created.



At this point choose “Finish” and the configuration will be saved and versioned in the repository. To confirm this, expand the “Configurations” node in the RON and you should see GTMS_R02.00.00 listed as a member. Expanding this node will reveal “GTMS_R02.00.00 1.0” which confirms the save and check-in have occurred. This ends the release configuration build process.

8.4.3.2 PromotionA promotion is the transfer of an application release from its current promotion state to the next promotion state in the promotion model. In terms of the Oracle Repository, this promotion involves:

Task Responsibility Notes on mechanismsInclude the application configuration in the next level workarea

Repository Manager Right click on workarea, and choose Edit workarea. Edit workarea specification.Note: Ensure that the latest release configuration is the FIRST entry in the workarea specification. This ensures that the latest versions are the ones included in the workarea. e.g.STVS R02.00.00STVS R01.03.00STVS R01.02.01STVS R01.02.00STVS R01.01.01STVS R01.00.02



In the case where a delivery has failed due to some vendor deficiency, the Work Area will need to be refreshed, based upon the fixes to the UDS. These fixes, done by the Application Configuration Manager, may or may not result in changes to the UDS membership. The Repository Manager will then be responsible for the subsequent generation of a new release configuration.

If the UDS membership has changed then the Work Area needs to be updated using the LATEST_UDS_CONTENTS, but picking the latest version of the UDS.

If the UDS membership has not changed then a simple refresh of the Work Area is sufficient.Regardless of the two scenarios it will be necessary for the Repository Manager to create a new version of the release configuration. There is only one supported method for creating the new version of the release configuration and it is very similar to the process initially used to create the first version. An overview of this process follows in Section 8.4.3.2.2.



8.4.3.2.1 Downloading Configuration Files for Staging Releases

After the release configuration has been created by the Repository Manager and checked-in it is necessary to download the database staging files in the configuration to the database server prior to applying the changes. There is a special “Private” workarea for the Repository Manager that is used for this purpose. The name of this workarea is “WA_DOWNLOAD” and it is only available for the Repository Manager’s use.

In order to use this workarea first expand the Private Workareas node in the RON and right click on the WA_DOWNLOAD workarea as per the following screenshot:



Choose “Edit Workarea” and the following screen dialog will be presented:



Click on the “Specification” tab and proceed to the following screen:

Choose “Edit” and proceed to the next dialog:



Click on the “Configurations” tab and choose the latest version of the delta configuration that you require in this workarea. There should only be one version of a configuration from any container visible in this workarea at any time,and it would usually be the latest version. An old version of a release config should be demoted prior to promoting the latest version. In the following example we are in the process of downloading the database release components for GTMS_R02.00.00 version 1.2.



Promote the configuration to the Members rules and configurations by clicking on the right arrow. The list will now look as follows:

In this view the order of the configurations in the Member rules and configurations list is not important and there is only one configuration from any container in this workarea at any point in time. Choose “OK” to continue



Finally Choose “Finish” to complete the changes and choose “OK” at the Refresh Workarea dialog. This completes the updating of the workarea with the new configuration.

The next step is to open the application container (eg. GTMS) in the WA_DOWNLOAD workarea and navigate to the “CM_non_generated” file folder as per the following screenshot.

Right click on this folder and choose “Download Files and Folders” and proceed with the next dialog:



In this dialog ensure that the “Recurse into sub-directories” check box is selected and the “To OS Path:” shows the path to the staging area on the database server. Note that this path will have to be locally mapped prior to downloading the release components. Press “OK” to download the files to the database server. The directory structure from the container will be preserved in the database server staging area.

It may be necessary to create an “Implementation” folder on the database server and flatten the directory structure of the release scripts into a single folder for staging if there are embedded calls to scripts which span multiple directories. This is an important step to take into account prior to executing the release scripts.

8.4.3.2.2 Updating Configuration after UDS Membership Changes/Updates

When an object which has membership in a UDS changes, the UDS should not be re-versioned by the developer. However the Repository Manager has to be notified by the developer that an object in the UDS has changed, and that the WA_DELIVERY_<APP>_ and WA_DELIVERY_<APP>_STAGE workareas have simply been refreshed. This triggers the creation of a new version of the existing configuration.

In the case of the UDS membership changing (eg. new file uploaded) then the developer must first update the rule list in the WA_DELIVERY_<APP> and WA_DELIVERY_<APP>_STAGE workareas to include the new UDS version as per the rule specification defined in Sections 8.4.2.1 and 8.4.2.2. After the rule lists have been updated and the delivery workareas refreshed then this triggers the creation of a new version of the existing configuration (as above).

The method for creating the new version of the release configuration is identical regardless of the above scenarios:

Create a new version of en existing configuration.

In the “Configurations” node in the RON expand the original configuration (eg. GTMS_R02.00.00) and right click on the latest version in the tree, which in this example is “GTMS_R02.00.00 1.0.



Choose “Edit Configuration”. The following screen will be presented:

Choose “Create a new version of an existing configuration”. The next screen dialog appears:

Enter the appropriate check out notes and Choose “OK” to continue:



In the above screen dialog choose “Re-create configuration from workarea” and enter the Workarea name (eg. WA_DELIVERY_GTMS_STAGE) and choose “From specification”. Choose “Next>” to proceed:



No action is required on this screen as it merely shows the rule list which has been pulled from the WA_DELIVERY_<APP>_STAGE workarea. Choose “OK” to continue.

No changes on this screen, choose “Next>” to continue:



At this stage it is necessary to perform some rudimentary QA on the element listing in this dialog to ensure that the rules are accurate. At this point click on the “Tree” tab and the following view will be shown:

Only the container name and version (eg. GTMS{1.0}) should be visible in this view. Please refer to the previous section (8.4.3.1) for an overview of the QA procedure for the release configuration membership and how to mitigate any issues.

Once any membership issues have been resolved choose “Next>” to proceed:



Again simply choose “Next>” to proceed:

Since this is not the initial attempt at creating the release config we will choose to “Just save configuration” which will not (physically) create version 1.1 of the release configuration, but will leave the configuration at version 1.0CO(1). Choose “Next>” to proceed and the “Check in” screen dialog will be presented.



Simply choose “Finish” at this point to complete the creation of the release configuration.

At this point you will need to compare the new version (not checked in) with the original. In order to do this right-click on the checked-out version and choose “Compare Previous Version”. This will initiate a Designer utility that will present the results of the comparison in a split-screen format as follows: The intent of using the compare function is to determine if there are indeed differences between the latest release configuration and the one that precedes it. The output will look something like the following:



Click on the “Show Differences” button ( ) to highlight the delta changes in the two configurations. You should see a difference reported in the next dialog, otherwise the developer has not properly managed the changes to the UDS.



If no changes are visible then it will be necessary to contact the developer to determine why no changes are being reported between the two configurations. Do NOT check-in the configuration. Instead right-click on the checked-out configuration and choose “Undo Checkout”. This will remove the configuration from the repository.

If the comparison checks out okay, then the last step is to finally Check In the configuration. Right click on the configuration and choose “Check-In”. Add the appropriate check-in notes and choose “OK” This will check-in the configuration and finish the process for creating the new release configuration. Choose “Edit->Requery All” in the RON to see the changes take effect.

8.4.3.2.3 Updating the Configuration

1. Remove deprecated versions of the same configuration from the WA_TEST_QA work area.

8.4.4 Pre-Configuration QA Checks

8.4.4.1 Set up WA_DELIVERY_<APP>For applications which have already been delivered, it is important to synchronize the configurations between WA_DELIVERY_<APP> and WA_PRODUCTION. Include all configurations that are currently in the WA_PRODUCTION environment by using the Edit Workarea Wizard: Rules Specification. Click on ‘Save to Specification File’, editing the resulting text file, and finally click on ‘Load from File…’ to synchronize the configurations, choosing the edited Specification File.



At the end of the promotion process, when the new release configuration has been promoted to WA_PRODUCTION, the delivery rules used in the WA_DELIVERY_<APP> workarea will be replaced by the new production configurations. This will be done by the Corporate Repository Manager.

8.4.4.2 List check-outs on UDS

Use the List checkouts utility to verify that all UDS elements and the UDS itself have been checked-in. Ensure you run the utility with the parameters as shown below, so that checked-out and non-versioned elements will be picked up as well as elements owned by any team member, not only by yourself.

If the utility returns any elements, the development team needs to check-in those elements before the configuration is created.

8.4.4.3 External references on UDSYou may run the external references utility on the UDS, to check the nature of external references, if any. External references are likely to exist for Delta UDSs.

External references may be OK. They need to be evaluated on a case by case basis. Examples of external references and their implications are:

1. Domain references: the UDS contains table or entity definitions that reference domains. These references can cause problems. For example:



If the missing domain is not in the workarea where the configuration will be promoted to, the user will not be able to see the reference

If the domain is present in the destination workarea, but it is an earlier version of the domain, with different definition, this would be confusing. The domain definition would have different specification than the attribute definition.

2. Relationship references: entities in the UDS have relationships to entities outside the UDS. This could be ok if:

The loss of visibility is intended: i.e. the entity outside the UDS is not ready for delivery, therefore the relationship to this entity should not be reviewed

The entity being referenced is already in the destination workarea

8.4.4.4 Container status

The container needs to be checked in. Otherwise it will not be possible to include the UDS in the configuration.

In the scenario where the UDS is simply being re-used to refresh a configuration with new versions, but all elements where already in the UDS, then there would be no loss of context if the container where not checked in. However it is good practice to check-in the container (but not necessarily all its contents) in preparation for each delivery.

8.4.4.5 External references on containerWhen building a full release configuration, based on an entire container, check the container for external references. External references need to be evaluated on a case-by-case basis.

Generally in the CS environments there should be no external references found. These would occur if CS starts to build shared application services or standards that are referenced by other applications.



8.4.4.6 List check-outs on container

If the configuration is being built based on the entire container, use List check-outs to verify that there are no un-versioned or checked-out elements.

8.4.4.7 Diagram opening check

If diagrams are being delivered, they need to be “open-able”. If, on diagram open, the user gets a pop up window indicating that not all elements are available, the diagram needs to be revised by the development team.

8.4.4.8 QA check for seeded applicationsIf the application contains seeded elements, use the Compare tool to compare the latest version of the container (i.e. the version being delivered) with the version that received the seeds (this version can be obtained by looking at the post-seeding configuration “on MAIN” created during the seeding process.

The container compare will identify seeded elements that may have been deleted from the application. In addition, it will also identify elements re-created with the same name as a deleted seed. Both situations require investigation.

NOTE: To obtain a list of all seeded elements in a container, you can use the WA_GENERAL_RM_TASKS workarea to view the contents of the ‘Enterprise Seed’ branch. Edit the workarea and use a single rule LATEST (‘Enterprise seed’). On refresh, the workarea will be populated only with seed elements for each application, leaving all other application objects behind. You can then use a repository report, custom query or simply a screen shot listing all elements available.

8.4.5 Post-Configuration QA Checks (WA_DELIVERY_<APP>)

8.4.5.1 Compare previous versionWhen creating a new version of an existing configuration, comparing to the previous version of the configuration will show the new added or removed elements. This list can be provided to developers as confirmation that the necessary changes were made.

8.4.5.2 Orphan filesAfter creating the configuration, in the RON, ensure that you do not see any files that are listed in a Files node right on root (as in the figure below). This indicates that those files do not have their full folder path in the configuration. This will cause the file to become not visible when promoted and should therefore be corrected.



Note: If you run into this situation, it means that the WA_DELIVERY_<APP>_STAGE workarea was not populated correctly. Either the application configuration manager forgot to include the full folder path for these files, or the UDS was edited and new files were included after the staging workarea was populated. Either way, the application configuration manager needs to revise the workarea rules since the new files may or may not be desireable in the release.

8.4.5.3 Diagram opening check

The purpose of this check is not the same as its pre-configuration counterpart. The pre-configuration check ensures that developers have been diligent in keeping their diagrams up-to-date as elements change. This post-configuration check ensures that no elements in the diagram were missed in the UDS. If elements in a diagram are missed, when the diagram is opened, it will present the same pop up window indicating that not all elements are visible.



8.4.6 Promotion from WA_TEST_QA to WA_PRODUCTION

1. In this scenario, the Repository Manager is implementing STVS_R02.00.00, and has invoked the Workarea Wizard, choosing ‘Edit Specification’ and clicking on the ‘Configurations’ tab.

The appropriate configuration is included as a member of WA_PRODUCTION..

2. The appropriate configuration is re-ordered to be at the top of all other member rules and configurations and the workarea is refreshed to complete the Promotion to WA_PRODUCTION.



3. The inclusion rules in the figure below in the WA_DELIVERY_<APP> Workarea, will be replaced by the new production configuration once the new configuration has been promoted to production.

4. The figure below shows the work area rules list for the WA_DELIVERY_<APP> work area after the promotion to WA_PRODUCTION has been completed.



5. The workaera rules for the WA_EMERGENCY_FIX workarea also need to be updated by adding the same configuration promoted to WA_PRODUCTION (i.e. the emergency fix workarea is always “ready” as a mirror of Production).

8.4.7 DemotionA demotion is the removal of the application release from the current promotion state environment, and placement of the application in the previous promotion state environment. In terms of the Oracle Repository, a demotion involves:

Task Responsibility Notes on mechanismsRemove the application configuration from the current workarea.

Application Owner/ Repository Manager

Right click on workarea, and choose Edit workarea. Edit workarea specification.Note: Ensure that the latest release configuration is the FIRST entry in the workarea specification. This ensures that the latest versions are the ones included in the workarea. e.g.STVS R02.00.00STVS R01.03.00STVS R01.02.01STVS R01.02.00STVS R01.01.01STVS R01.00.02

NOTE: If Users do not accept the system in WA_TEST_QA, then the vendor will need to make corrections in WA_DEVELOPMENT and promote again from there.

8.4.8 Non-release-based (exception) configurationsConfigurations may be used occasionally to represent a list of elements that satisfy particular requirements during the life of the application. Such requirements are generally exceptions that need to be addressed. They do not originate from the regular development and maintenance process. Examples of non-release-based configurations are:

Data fix: A data error or inconsistency is found which requires correction. The existing application functions do not provide a means to correct the data. Therefore a set of data correction scripts is prepared to remedy the situation. This set of scripts is not part of a release. It simply addresses a problem requiring immediate action.

NOTE: a data fix event should trigger a patch release that would correct the application component that is allowing the data inconsistency to occur.

Data load: A data load is required, for example, because a new branch or department will start to use the application, and a new set of codes specific to that department’s business needs to be added to the database.



NOTE: most data loading happens during the data conversion process that takes place when new application releases go to production. Therefore a load mid-way through the life of an application is an exceptional event.

8.4.8.1 Precursor User Defined SetUser Defined Sets are used as a basis to define exception configurations. The naming convention is

<Application>_<exception>_<date> (e.g. STVCMS_DATA_FIX_20060215).

This User Defined Set contains all scripts and data files needed to address the issue, as well as a document describing the nature of the data issue and what it will look like when it is fixed.

8.4.8.2 After the exception configuration is createdAfter the exception configuration is created it is used by the Corporate Repository Manager to populate a temporary workarea (WA_DOWNLOAD) used to extract the configuration components. The configuration is not promoted through the promotion model workareas.

8.4.9 Transfer of Application VersionA transfer of an application version is the transfer of the application configuration from (or to) WA_TEST_QA to (or from) the WA_ON_HOLD environment. It is used in the event that the promotion of a particular release of an application is put on hold or the resumption of activity. In terms of the Oracle Repository, a transfer involves:

Task Responsibility Notes on mechanismsRemove the application configuration from the current workarea.


Right click on container, and chose Edit workarea. Edit workarea specification.

Include the application configuration in the target workarea.


Right click on workarea, and chose Edit workarea. Edit workarea specification.



8.4.10 Transfer of Entire ApplicationA transfer of an entire application is the transfer of the application container from (or to) WA_DEVELOP to (or from) the WA_ON_HOLD environment. It is used in the event that the current development of an application is put on hold or the resumption of activity. In terms of the Oracle Repository, a transfer involves:

Task Responsibility Notes on mechanismsExclude the application container from the current workarea.


Right click on application container, and choose Exclude from workarea.

Include the application container in the target workarea


Right click on target workarea, and choose Edit workarea. Include in Workarea. (Container can be found in the “All Containers folder”

8.4.11 Archive of Application VersionAn archival is the removal of an application configuration from the WA_PRODUCTION environment, and placement of the application in the WA_ARCHIVE environment. In terms of the Oracle Repository, an archive involves:

Task Responsibility Notes on mechanismsRemove the application configuration from the current workarea(s).



Include the application configuration in the target workarea.


Right click on workarea, and chose Edit workarea. Edit workarea specification.

8.4.12 Archive of Entire ApplicationAn archival is the removal of an application container from the WA_DEVELOP environment, and placement of the application in the WA_ARCHIVE environment. In terms of the Oracle Repository, an archive involves:

Task Responsibility Notes on mechanismsRemove the application configuration from the current workarea(s). (If applicable)



Exclude the application container from the current workarea.


Right click on application container, and choose Exclude from workarea.

Include the application container in the target workarea


Right click on target workarea, and choose Edit workarea. Include in Workarea. (Container can be found in the “All Containers folder”



8.5 Workarea Rules used during Delivery

8.5.1 Inclusion Rules

LATEST_UDS_CONTENTS

This rule includes all elements that are members of a User Defined Set element. Note that this rule must be accompanied by the INCLUDE_FOLDER_VERSION rule whenever the UDS has files in its membership list.

INCLUDE_OBJECT

This rule includes a single object from the application. Use this rule to include the UDS itself into the release (or delivery workarea).

UDS_MEMBER_PARENT_FDL

Use this rule in conjunction with LATEST_UDS_CONTENTS rule whenever the UDS includes files. This rule will bring in the immediate parent folders for each file in the UDS.

INCLUDE_FOLDER_VERSION

INCLUDE_FOLDER_VERSION is meant to allow you to include specific versions of the folders you need. You use INCLUDE_FOLDER_VERSION to bring in folders that are within the folder path, but at higher levels than the immediate parent folders of files in your UDS.

You only need to use this rule to include the parent folder of a folder that has been newly created and does not exist in the delivery workarea (due to inclusion of production releases). For example if a new folder was created during the current development/maintenance project, it will not yet be in any production configuration. This means that its immediate parent folder was necessarily versioned to include the new sub-folder. If you do not include this new version of the parent folder, the newly created folder (and its contents) will not show up.

8.5.2 Exclusion rules (optional)

EXCLUDE_LATEST_UDS_CONTENTS

Application containers in Oracle SCM may contain elements that are not really application release components. Examples of such elements are utility scripts or query/test forms developed during the project.



These are useful to developers, but should not make their way into the test and production environments. When they do, they usually cause confusion to staff deploying the application, as they do not seem to be connected to the application in any way and may sometimes not even compile. The User Defined Set element is used to create release exclusion lists.

Exclusion lists are relevant only for full application releases. Release deltas only contain required elements which are applied on top of a full release. The naming convention for these exclusion UDS’s is “<application acronym> <release number> exclusions", such as “CIRR_R01.00.00 EXCLUSIONS”.

8.6 Workarea rules used for parallel maintenanceThe set up of the parallel maintenance workarea will depend on the situation at hand. The workarea rules used will vary, except for the first rule (top of the list) which is always LATEST(PARALLEL_MAINTENANCE). This will ensure that versions on that branch will be visible.

The two most common scenarios for populating this workarea beyond ‘LATEST on branch’ are:

1. Populate using the current production release configuration(s): in this case, none of the changes made in the development workarea are deemed useful to the parallel maintenance effort.

60. Populate using INCLUDE_FOLDER(<application name>): This will bring in the latest versions available for all application elements. Thus the changes that have been made in the development workarea will be visible to the parallel maintenance team.

8.7 Workarea rules used for emergency fixesThe set up of the emergency fix workarea always uses the following rules:

1. LATEST(EMERGENCY_FIX): This will ensure that versions on this branch will be visible.

61. Production configuration(s): This will ensure that the emergency fix is applied to the production release elements.

8.8 Merging

8.8.1 General (read this first)Before you merge elements or containers, ensure that you have checked-in both the branch version (your emergency fix or parallel maintenance work) and any work-in-progress you may have on the MAIN branch (even if it is not “complete”). This will ensure you have a savepoint for an eventual rollback.

When merging, the merge wizard will guide you through all the content that is candidate for merging between source and target.

The wizard will present two types of candidate content: differences and conflicts.



Differences show up as pre-selections. The merge wizard will provide a selection based on what it thinks you want to do. In figure below, the wizard proposes that the attribute GENDER be merged to the MAIN branch.

Conflicts are content which the wizard cannot reconcile or make a decision on its own. These will not be pre-selected and you must make a selection yourself. The figure below shows one example of conflict: a name change in an entity. You must decide if the entity should be called PERSON or HUMAN RESOURCE.



Conflicts may also appear in source code.

If the wizard has not identified any conflicts, it will go to the end of the merge list when you click on Next Conflict.

Observe the colour key buttons at the top of the window. They show the colours for Base, Target and Source versions. This makes it easier to identify the version in the list of differences and conflicts.

Note that in a merge there are always three versions involved: source, target and base. The base version is the “common ancestor”. This is the one common version that you come to if you navigate backwards in the version tree from both source and target. You can also direct the wizard to pick from this base version if you’re not happy with the content of either source or target.

8.8.2 Container mergesDuring the software development process developers are likely to delete checked-in elements from a container from time to time. These elements are deemed no longer necessary. Occasionally, through further analysis, the deleted elements are found to be useful.

Instead of re-creating the elements from scratch, it is recommended that a container merge be used to retrieve the elements from an earlier version of the container.



8.8.2.1 Merge pre-requisites1. The target container must be checked-out.

62. Always perform the merge in a workarea that contains the checked-out target container.

63. Always do a Compare between the target and the source version before merging. This will show you all elements available in the source, which can be brought forward to the target. Use the results of the compare to guide your merge procedure.

8.8.2.2 Where to mergeAlways use the RON to merge elements. Select the target container, then select ‘Merge…’ from the Version pull-down menu.

8.8.2.3 How to merge1. Select the target checked-out container.

When merging to recover files in the source code sub-folders, you should select the immediate parent folder of the files you want to recover. Do not select the application container (e.g. CIDR, CIRRAS) unless you want to merge metadata elements.

64. Select ‘Merge…’ from the Version pull-down menu.

65. Select the source container version for the merge (the one that has the elements you want to bring forward to the current container version.You may have to look in the All Containers node to find the container version that has the elements you need to recover.)



66. In the merge confirmation window, ALWAYS select ‘Use merge window’.

67. The merge wizard will provide a screen that shows all differences, with the wizard’s best guess at the intended result. This guess is always to bring forward what’s not at the target.



68. Check the colour key at the top of the screen. Then scroll down the page until you find each merge candidate that has the same colour as the ‘Base’ version. These are the elements that are at the base (source) and need to be merged into the target.

a. For each of these elements, you have to decide if you want it brought forward to the destination.

b. If you DON’T want the element, then check the destination version as your choice. Note that when you do this, it will hide the listed element.



c. If you DO want the element, then ensure the source version is checked, and the target unchecked.



69. Use the “Next conflict” and “Previous conflict” buttons to find conflicts. These are issues that the wizard cannot resolve, and thus require you to make a decision. (Conflicts are more common when merging programs or metadata, however you do need to perform this check here.)

70. Once you’re done selecting the elements you want, press the Save button.

71. The wizard will notify you of which elements will be brought back to the workarea. This makes sense since these elements where not in the workarea before the merge.

Depending on the number of elements merged, the wizard may take up to several minutes to complete the merge.



8.8.3 Element mergesElement merges are used to merge EMERGENCY FIXes and PARALLEL MAINTENANCE changes back into the element’s MAIN branch.

8.8.3.1 Merge pre-requisites1. The target element version must be checked-out

72. The source version should be checked-in

73. Always perform the merge within the workarea that contains the target version. I.e. perform the merge in the WA_DEVELOPMENT workarea

74. Always compare source and target versions before merging. Use the compare results to guide you through the merge. You may have to discuss with your peers which changes should be merged back to MAIN and which are irrelevant.



8.8.3.2 Where to mergeAlways perform the merge in the RON, using the Version Merge option from the pulldown menu.

8.8.3.3 How to merge1. In the WA_DEVELOPMENT workarea, select the element that is the target of the merge. (This

element is the leaf node on the MAIN branch for that element.)

75. Select Version Merge from the pull-down menu.

76. Select the version that is the source for the merge (this version should be the leaf node on the branch that contains your parallel changes (either EMERGENCY FIX or PARALLEL MAINTENANCE branch)

77. Select “Use merge window”.



78. Go through each difference (use the Next Difference/Previous Difference buttons to navigate through these) and make your selection.

o Ensure that you bring back to MAIN all changes that are still applicable. In this case the version with the check box checked should be the one on the branch.

o You must select the target version (on MAIN) when you do NOT want a difference to be brought to the target.



79. Use the Next Conflict/Previous Conflict buttons to navigate through the conflicts. You also must make a decision on these. (If there are no conflicts, the wizard will go to the end of the merge list.)

80. Press Save when done.

81. Re-query when back in the RON after the merge.



9 RELEASE MANAGEMENT

9.1 Versioning of base release or patch configuration Versioning of configurations is permitted during the approval process for that configuration but cannot be updated once the application has been placed in production.

Configuration managers are allowed to update a configuration to reflect new element versions created as a result of problems found during the test and quality assurance processes. Required changes are done in the WA_DEVELOP work area, and added to the configuration after check-in. No element changes are done in the WA_TEST_QA environments.

10 ADDITIONAL REPOSITORY ENVIRONMENTSRepository managers will use two additional workarea, which are restricted to the REPOSITORY MANAGER account.

WA_GENERAL_RM_TASKS: this shared workarea is used by repository managers to perform miscellaneous tasks such as retrieving past application releases, doing release comparisons, etc. The workarea rules for this environment are very volatile and will depend on the task at hand.

WA_DOWNLOAD: this private workarea is used by repository managers to download specific configuration files for implementation into either the ministry UAT or Production environment. The workarea rules for this environment will always contain the latest configuration for an application container.

11 CONCLUSIONThe standards described in this document establish a Designer 10g repository environment that will enable configuration management and release management for all application development initiatives within the Ministry of Community Services and Ministry of Tourism, Sport and the Arts.
