Oracle Designer SCM Guide - (CS/TSA) Ministry of Community Services Ministry of Tourism, Sport and the Arts
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Oracle Designer SCM Guide
Ministry of Community Services
Ministry of Tourism, Sport and the Arts
(CS/TSA)
Table of Contents
1 Version Control ......................................................................................... 4
2 INTRODUCTION ........................................................................................ 5
2.1 Audience......................................................................................................................... 5
2.2 Purpose .......................................................................................................................... 5
2.3 Assumptions ................................................................................................................... 6
2.4 SCM Vendor meeting prior to project commencement ................................................... 6
2.5 Other Documents............................................................................................................ 6
3 Configuration Management - background.............................................. 6
3.1 What is Configuration Management................................................................................ 6
3.2 Software Configuration Management (SCM) .................................................................. 7
4 DEFINITION OF TERMS ............................................................................ 7
4.1 Element........................................................................................................................... 7
4.2 Version tree .................................................................................................................... 7
4.3 Container ........................................................................................................................ 8
4.4 File Folder Structures...................................................................................................... 8
4.4.1 Database files (DDL/DML) Scripting Standards.............................................................................10
4.5 Workarea ...................................................................................................................... 11
4.6 Configuration ................................................................................................................ 11
4.7 Promotion model........................................................................................................... 11
5 Repository–wide policies....................................................................... 12
5.1 Versioning policies ........................................................................................................ 12
5.1.1 Automatic branching ......................................................................................................................12
5.1.2 Automatic version labeling .............................................................................................................14
5.1.3 Strict locking...................................................................................................................................14
5.2 Names of files and folders ............................................................................................ 14
5.2.1 Case sensitive uniqueness checking .............................................................................................14
5.3 Dependencies............................................................................................................... 14
5.3.1 Copy on versioning ........................................................................................................................15
5.3.2 Copy on copying ............................................................................................................................15
6 Security.................................................................................................... 15
6.1 Database ...................................................................................................................... 15
6.2 Repository..................................................................................................................... 15
6.3 Roles............................................................................................................................. 17
6.4 Workareas .................................................................................................................... 17
6.5 Containers .................................................................................................................... 18
6.6 Configurations............................................................................................................... 19
7 Seeding of applications with Enterprise standards ............................ 19
7.1 What gets seeded ......................................................................................................... 19
7.2 Seeding workarea ......................................................................................................... 20
7.3 The seeding process..................................................................................................... 20
7.3.1 Seeding an empty container ..........................................................................................................21
7.3.2 Seeding an existing container for the first time ..............................................................................23
7.3.3 Adding new seed domains to a previously seeded container........................................................25
7.3.4 Upgrading previously seeded domains..........................................................................................28
7.3.5 Copying seed domains...................................................................................................................30
7.4 Verifying updates to seeded elements .......................................................................... 32
8 PROMOTION MODELS ........................................................................... 33
8.1 Development Promotion model..................................................................................... 33
8.2 Parallel maintenance promotion model......................................................................... 35
8.3 Emergency fix promotion model ................................................................................... 37
8.4 Promotion management procedures............................................................................. 39
8.4.1 Overview ........................................................................................................................................40
8.4.2 Delivery ..........................................................................................................................................41
8.4.3 Release Build and Promotion.........................................................................................................53
8.4.4 Pre-Configuration QA Checks........................................................................................................75
8.4.5 Post-Configuration QA Checks (WA_DELIVERY_) ...........................................................78
8.4.6 Promotion from WA_TEST_QA to WA_PRODUCTION ................................................................80
8.4.7 Demotion ........................................................................................................................................82
8.4.8 Non-release-based (exception) configurations ..............................................................................82
8.4.9 Transfer of Application Version ......................................................................................................83
8.4.10 Transfer of Entire Application.........................................................................................................84
8.4.11 Archive of Application Version .......................................................................................................84
8.4.12 Archive of Entire Application ..........................................................................................................84
8.5 Workarea Rules used during Delivery........................................................................... 85
8.5.1 Inclusion Rules...............................................................................................................................85
8.5.2 Exclusion rules (optional) ...............................................................................................................85
8.6 Workarea rules used for parallel maintenance.............................................................. 86
8.7 Workarea rules used for emergency fixes..................................................................... 86
8.8 Merging......................................................................................................................... 86
8.8.1 General (read this first) ..................................................................................................................86
8.8.2 Container merges...........................................................................................................................88
8.8.3 Element merges .............................................................................................................................94
9 RELEASE MANAGEMENT...................................................................... 98
9.1 Versioning of base release or patch configuration ........................................................ 98
10 ADDITIONAL REPOSITORY ENVIRONMENTS ..................................... 98
11 CONCLUSION.......................................................................................... 98
Ministry of Community Services
1 Version Control
Ver. Description Date Author Org.
0.1 First Draft 2003-NOV-10 Scott Petersen SBD
0.2 Revised based on feedback 2002-DEC-18 Scott Petersen SBD
1.0 Bea’s feedback 2003-JAN-14 Gary Wong SBD
1.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_ conventions 2004-MAY-14 Gary Wong SBD
1.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__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 BSC
1.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 BSC
1.14 Update to reflect change to Ministry name(s) and update wording to reflect Rob Gretchen /
upgrade from Oracle Designer 6i to 10g. 2006-FEB-03 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 Guide
Thu, Aug 10, 2006 Version 1.14 Page: 4
Ministry of Community Services
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 Audience
The 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 Section 8.4, 8.5 ( Sections 2-6
Configuration Manager)
2.2 Purpose
The 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.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 5
Ministry of Community Services
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 commencement
It 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 Management
Configuration 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.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 6
Ministry of Community Services
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 Element
At 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 tree
Configuration 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.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 7
Ministry of Community Services
PARALLEL MAIN EMERGENCY
MAINTENANCE FIX
1.0
1.1
1.2
1.1 1.0.3.1
1.1.1.0
1.0.2.2
1.2.1.0 1.3
1.1 1.0.3.2
1.1.1.1
merge
4.3 Container
A 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 Structures
The 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_generated
CM_non_generated\admin
CM_non_generated\dataconv
CM_non_generated\db_objects
CM_non_generated\doc
CM_non_generated\install
CM_non_generated\non_db_source
CM_non_generated\www
CM_non_generated\db_objects\schema folders
CM_non_generated\db_objects\schema_app folders
CM_non_generated\db_objects\schema_case folders
CM_non_generated\db_objects\schema folders\Indexes
CM_non_generated\db_objects\schema folders\Sequences
CM_non_generated\db_objects\schema folders\Synonyms
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 8
Ministry of Community Services
CM_non_generated\db_objects\schema folders\Tables
CM_non_generated\db_objects\schema folders\Triggers
CM_non_generated\db_objects\schema folders\Views
CM_non_generated\db_objects\schema_app folders\Functions
CM_non_generated\db_objects\schema_app folders\Javascripts
CM_non_generated\db_objects\schema_app folders\Package bodies
CM_non_generated\db_objects\schema_app folders\Packages
CM_non_generated\db_objects\schema_app folders\Procedures
CM_non_generated\db_objects\schema_app folders\Type bodies
CM_non_generated\db_objects\schema_app folders\Types
CM_non_generated\db_objects\schema_case folders\Functions
CM_non_generated\db_objects\schema_case folders\Javascripts
CM_non_generated\db_objects\schema_case folders\Package bodies
CM_non_generated\db_objects\schema_case folders\Packages
CM_non_generated\db_objects\schema_case folders\Procedures
CM_non_generated\db_objects\schema_case folders\Type bodies
CM_non_generated\db_objects\schema_case folders\Types
CM_non_generated\non_db_source\forms
CM_non_generated\non_db_source\icon
CM_non_generated\non_db_source\java
CM_non_generated\non_db_source\other
CM_non_generated\non_db_source\reports
CM_non_generated\non_db_source\sql
CM_non_generated\www\html
CM_non_generated\www\icon
CM_non_generated\www\img
The Ministry standard folder structure for project deliverables is:
CM_project_deliv
CM_project_deliv\AppDev
CM_project_deliv\BusReqDefn
CM_project_deliv\ConfMgmt
CM_project_deliv\CtrlRep
CM_project_deliv\DataConv
CM_project_deliv\DBDsgnBld
CM_project_deliv\Doc
CM_project_deliv\ExSysExam
CM_project_deliv\ProjMgmt
CM_project_deliv\QualMgmt
CM_project_deliv\ResMgmt
CM_project_deliv\Support
CM_project_deliv\TechArch
CM_project_deliv\Testing
CM_project_deliv\Training
CM_project_deliv\Transition
CM_project_deliv\WorkMgmt
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 9
Ministry of Community Services
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 Select the file. Then select "Download Files and Folders" (either from the
file 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 Standards
It 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.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 10Ministry of Community Services
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 Workarea
A 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 Configuration
A 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 model
A 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
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 11Ministry of Community Services
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 policies
Repository-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 policies
Versioning policies control tool behaviour on check-in and check-out operations.
5.1.1 Automatic branching
When 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)
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 12Ministry of Community Services 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. Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 13
Ministry of Community Services
5.1.2 Automatic version labeling
When 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., where 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 .1., where
.is the version label of the element that provides the source for
the new branch, and is a number starting in 0 and incremented at every check-in
5.1.3 Strict locking
When 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 checking
When 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 Dependencies
The 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
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 14Ministry of Community Services
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 versioning
When selected, causes object dependencies to be copied by default when a new version of an object is
created.
5.3.2 Copy on copying
When selected, causes object dependencies to be copied by default when an object is copied.
6 Security
Security 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 Database
Each 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_
e.g. CASE_SSMITH
6.2 Repository
The 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”
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 15Ministry of Community Services
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.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 16Ministry of Community Services 8. Click OK 6.3 Roles There 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 Workareas The 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 Oracle Designer SCM Guide Thu, Aug 10, 2006 Version 1.14 Page: 17
Ministry of Community Services
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 REPOSITORY Public Role
Configuration MANAGER
Manager
WA_DEVELOPMENT ALL Select, Insert, Update, Delete,
Version
WA_DELIVERY_ Update Spec, ALL Select
Compile
WA_DELIVERY__STAGE Update Spec, ALL Select
Compile
WA_TEST_QA ALL Select
WA_PRODUCTION ALL Select
WA_PARALLEL_MAINTENANC ALL Select, Update, Version
E Note: 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 Select
WA_GENERAL_RM_TASKS ALL
WA_ENTERPRISE_SEEDING ALL
WA_BLOCK_SEEDED_CHECKO ALL
UTS
6.5 Containers
The 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
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 18Ministry of Community Services
6. Check the needed options in the “To Grant” column.
Note: Do not grant “Update Spec”, “Compile” or “Administrate” even if they are available
Note: Generic users should get SELECT access ONLY.
7. Check the “Recurse Sub-Containers” option
8. Click the “Grant” button”
9. Click “OK”
6.6 Configurations
The 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 seeded
The 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.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 19Ministry of Community Services
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 workarea
The 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 process
NOTE: 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.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 20Ministry of Community Services
To seed an application container, follow the steps in the appropriate scenario below:
7.3.1 Seeding an empty container
In 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
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 21Ministry of Community Services
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 ‘ 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 ‘ 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.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 22Ministry of Community Services
8. In the WA_BLOCK_SEEDED_CHECKOUTS workarea, edit the workarea to include the
‘ 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.
a. 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 time
In 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.
a. 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.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 23Ministry of Community Services
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.
b. If no matching domains exist: proceed with the seeding process.
2. Ensure that the entire container and contents are checked-in in WA_DEVELOPMENT.
3. Create a savepoint configuration with the entire container contents (using INCLUDE_FOLDER
rule), as a rollback position .
4. Edit the WA_ENTEPRISE_SEEDING workarea:
a. 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.
b. Take note of the configuration name and version as you will need it later in this process.
c. Use the INCLUDE_FOLDER rule to include the target container in the workarea.
5. Check-out the target container.
6. Follow steps in the ‘Copying seed domains’ section later in this document.
7. Select the application container and all domains you’ve created or checked-out 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 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.
8. Create a configuration representing the contents of the application after seeding, on enterprise
seed.
a. Name the configuration ‘ seeded elements on Enterprise Seed’
b. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on branch
Enterprise seed.
c. Check-in the configuration
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 24Ministry of Community Services
9. 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.
10. Create a configuration representing the contents of the application after seeding, on the MAIN
branch. Name it ‘ 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.
b. Check-in the configuration.
11. In the WA_BLOCK_SEEDED_CHECKOUTS workarea, edit the workarea to include the
‘ seed baseline on MAIN’ configuration created in the previous step.
12. 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.
a. 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.”
13. Refresh the development workarea to include the new application version.
7.3.3 Adding new seed domains to a previously seeded container
In 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.
2. Create a savepoint configuration with the entire contents of the application to be seeded, on the
MAIN branch.
a. Use the INCLUDE_FOLDER rule and select the latest container version on MAIN.
3. Edit the WA_ENTEPRISE_SEEDING workarea:
a. 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.
b. Take note of the configuration name and version as you will need it later in this process.
c. 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).
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 25Ministry of Community Services
4. Check out the target container
5. Follow steps in the ‘Copying seed domains’ section later in this document.
6. Select the application container and all domains you’ve created 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.
7. Update the configuration representing the contents of the application after seeding.
a. Check-out the latest version of the ‘ seeded elements on Enterprise
seed’
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 26Ministry of Community Services
b. Use the INCLUDE_FOLDER rule with the seeded application as the folder, on branch
Enterprise seed.
i. NOTE: you have to go to the ‘All Containers’ node to select the container
version on MAIN.
c. Check-in the configuration
8. 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.
9. Create a configuration representing the contents of the application after seeding, on the MAIN
branch. Name it ‘ 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.
b. Check-in the configuration.
10. In the WA_BLOCK_SEEDED_CHECKOUTS, un-do the check-outs of all elements check-
out for the seeded container. Workarea.
11. Edit the workarea to include the ‘ seed baseline on MAIN’ configuration
created earlier.
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 27Ministry of Community Services
12. 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.
a. 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.”
13. Refresh the development workarea to include the new application version.
7.3.4 Upgrading previously seeded domains
In 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.
2. Create a savepoint configuration with the entire contents of the application to be seeded, on the
MAIN branch.
a. Use the INCLUDE_FOLDER rule and select the latest container version on MAIN.
3. Edit the WA_ENTEPRISE_SEEDING workarea:
a. 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.
b. Take note of the configuration name and version as you will need it later in this process.
c. 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).
4. Check-out each domain you want to update.
5. Manually edit each domain you want to update.
6. 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.
7. Update the configuration representing the contents of the application after seeding.
a. Check-out the latest version of the ‘ seeded elements on Enterprise
seed’
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 28Ministry of Community Services
b. Use the ‘Refresh all existing members with their latest versions’ option. The new
versions on Enterprise seed branch will be picked up.
c. Check-in the configuration
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 29Ministry of Community Services
8. 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.
a. 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.
9. Create a configuration representing the contents of the application after seeding, on the MAIN
branch. Name it ‘ 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.
b. Check-in the configuration.
10. In the WA_BLOCK_SEEDED_CHECKOUTS, un-do the check-outs of all elements check-
out for the seeded container. Workarea.
11. Edit the workarea to include the ‘ seed baseline on MAIN’ configuration
created earlier.
12. 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.
a. 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.”
13. Refresh the development workarea to include the new domain versions.
7.3.5 Copying seed domains
1. In the Enterprise container, select all the domains you want to use for seeding.
2. Select Utilities Æ Extended Copy
3. 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.)
Oracle Designer SCM Guide
Thu, Aug 10, 2006 Version 1.14 Page: 30You can also read
