Вы находитесь на странице: 1из 9

Application Change Management Pack

Subversion Best Practice


Volker Eckardt
e-business consulting
volker.eckardt@cp-ebusiness.com www.cp-ebusiness.com

Agenda

ACMP Overview ACMP and Subversion Q&A

AMP and ACMP


Application Management and Change Management Pack
Enterprise Manager Grid Control

Application Management Pack


Discovery Monitoring Cloning

Oracle E-Business Suite Packs

Customization Manager

Patch Manager

Setup Manager

Application Change Management Pack

ACMP Major Features


Customization Manager
Support a wide variety of file types Bundle customizations so that EBS standard patching tool can consume them Tool to manage a high number of files Better, more efficient reporting of customizations by instance Eliminate redundant, error-prone practice of command-line patching Provide a centralized console for all patching activities and history Leverage and enhance existing patching tools/practices Reduce system downtime due to optimized patching flow

Patch Manager

Setup Manager

Enforce dependencies among related data Bundle discrete extracts into complex, reusable packages Reduce time to propagate setups to other instances Enable customers to run their own custom extracts/loads

ACMP Architecture

Agent
R12

OEM 11g
Agent AMP ACMP

R12

V4.0
Agent

11i

Cloning Data Scrambling System Management

Patches Customizations Setup

OEM 12c + Packs V12.1.

In this Section
Best Practice using Subversion together with ACMP
Subversion Structure Main Development Area Code Releases Packaging Branching Readme

Subversion Structure
Requirement
Develop 3 CEMLIs, one for Payables, another for Inventory and a third for Service

Payables CEMLI Inventory CEMLI Service CEMLI

CEMLI = Configuration, Extension, Modification, Localization, Integration (in EBS context)

Main Development Area


The main development area within SVN is trunc

And every CEMLI beneath can have a detailed directory structure


Place for modified code (avoid if
possible)

Place for Extensions


Custom Table Registration

Code Releases
As the code development goes on, we will reach a stage to release a code set Code releases are transferred into the release folder (just a synonym for tag)

Additional Release Identifier in between

use

Packaging
Whereas Code Packaging can be performed from any place, the default is the release tree To keep the package definition as static as possible, we suggest to reuse the user name field as release identifier and adapt the command accordingly

Release requested

Modified Command

cat svn://<svn-server>/releases/%username%/%product_code%/%file_path%/%file_name%@%version% > %file_name% cat svn://<svn-server>/releases/V1.0/%product_code%/%file_path%/%file_name%@%version% > %file_name%

10

Branching
To use when you continue with certain development without disturbing the main path (trunc) Such an area could also act for bug fixing for Release 1, whereas Release 2 is already in development (continued in trunc) Branches are parallel to trunc, and can be merged back into trunc when needed
Branch Identifier in between

11

Branches and Releases


To release code developed in the branches area, we suggest:
a) transfer it into the release folder (in case of bug fixes for Release 1) or b) merge it back into the trunc to fix a known issue for the planned Release 2
a) Provide releases from Branch use

b) Merge changes back into ongoing development

use

12

Branches and Releases


It may be required to package out of the branch folder The branch abbreviation can be again entered flexible and finally derived from the variable %username%

see also slide 6 titled Packaging

13

Readme
It is suggested to create a readme and place it inside your package (txt and html types are automatically recognized by ACMP for copy only) The default path should be readme or just a . Use a template to cover the main sections, such as
Pre Installation Tasks Installation Tasks Post Installation Tasks

Pre defined content will guide the developers to complete it quickly If certain documents are related to this development, additional links pointing to such documents can be helpful too

14

CEMLI readme Template

15

Readme Handling
A readme file as part of the patch

To resolve version issues a name like CEMLI020_readme.txt will be better

Single dot will do

16

Code Rules
There are a number of code rules to follow, otherwise adpatch will not accept the patch as a whole Such code rules are usually header information (like adpatch instructions) and closing lines (like an exit; in sql files) ACMP runs a built-in file checker every time you package your custom files. This will also help validating in advance. The $Header$ tag will be recognized, but only the version number will be changed. Therefore you need to enter the correct $Header$ line. Additionally, the Subversion tag $Id$ can be added to derive the version info during check-in In case of binaries the file name has to match exactly
See ACMP User Guide Chapter 3-4

17

ACMP and Subversion, Best Practice

Thank You!

Volker Eckardt
e-business consulting
volker.eckardt@cp-ebusiness.com www.cp-ebusiness.com

Вам также может понравиться