Kintana – Change Management System

Table of Contents

INTRODUCTION:.............................................................................................................................................................1
INTEGRATION WITH RCS (ONLY FOR ORACLE CODE, SIEBEL IS NOT INTEGRATED WITH RCS) :.................................2
MIGRATION PROCESS :...................................................................................................................................................3
Specific for Oracle....................................................................................................................................................3
Create a new report to Check-In OR Check-Out code (Only for Oracle):..............................................................4
Creating Package and Migrating (For Oracle and Siebel ) :..................................................................................9
RELEASE WINDOW :.....................................................................................................................................................13
Oracle migrations to Production Environment:.....................................................................................................14
Points to be taken care while migration :.....................................................................................................................14
INTRODUCTION:
Kintana automates migrations and deployments of software changes across system landscape, from
development to test, staging, and production. It covers changes in code, configurations, and
content to enterprise applications such as Oracle, Siebel, etc, as well as to custom and legacy
systems, Web sites, and networks.

Using Kintana, now a part of Mercury Change Management, you can digitize your change
management best practices and methodologies to uniformly plan, deploy, and manage changes,
hiding the complexity of version control and testing tools while leveraging their functionality. Our
integrated approach also lets your analysts, developers, testers, database administrators, and
operators collaborate effectively through automated best-practice processes, improving quality and
speed while lowering costs.

First Screen of Kintana Workbench, when you log in (as admin)

Integration with RCS (Only for Oracle code, Siebel is not integrated
with RCS):

Kintana is integrated with RCS (version control tool). RCS is installed on erp11i-dev box where
11i Dev environment is set up (IDEV1).

When a file is check in, developers place the file in RCS_HOME/**, but when the file is checked
out, Kintana places the file in RCS_HOME/stage/** directory and developer picks up the file from
stage/** directory.

For Forms (.fmb), Library (.pll) and Reports (.rdf), use ASCII converted format (ie .fmt, .pld and
.rex respectively) to migrate. Don’t migrate any code with in Binary format.
Migration Process:

RCS Check In

Specific for Oracle

Developers place the code in RCS Home (on erp11i-dev box) under appropriate directory and then
run Check In / Check Out reports from Kintana and then create Kintana packages to migrate the
code. Following sections describe how to run reports and create packages and migrate.

Click
here to
run
reports
Create a new report to Check-In OR Check-Out code (Only for Oracle):

Click
here
to
creat
ea
new
repor
t
Run VC - Check In report to check in and VC - Check Out report to check out the files.

Repo
rt to
check
in
code
Check in report with appropriate parameters

Hit
subm
it to
run
the
repor
t
Check Out report with appropriate parameters:

If
checking
out file
for read-
only
purpose,
please
make
sure you
do not
lock the
file

While
checking
out,
Destinatio
n should
be VC-
Staging
Creating Package and Migrating (For Oracle and Siebel):

Creating a new package

Click
here to
create
a new
packag
e
Selecting a Workflow:

Please put
in
Description

Click
here to
select
workflo
w from
the list
of values
Creating a Package Line

Creating
a new
package
line
Selecting appropriate parameters:
Submit the package:

Submit
the
packag
e
Release Window:

Oracle migrations to Production Environment:

Oracle migrations to IPROD are during migration windows (twice a month) after 6PM. Developers
create packages and test the migration on non-production instances and OPS team take care of
deployment to Production.

Points to be taken care while migration:

DO NOT migrate anything to PROD until you get due approvals (verbal or via email) from
Development Managers and APPS OPS Manager

For Oracle Code: DO NOT ever delete “, v” file from RCS HOME. In case you delete it
mistakenly, you can not check in/check out/migrate that file again with the same name.
Workarounds are, either you have to rename the code file and check it in and kintana will take it as
a fresh file and start the versioning with 1.0, OR need to delete the records from Kintana database
for old file (which is not preferred).

Most of the sequence (of migration) is taken care by Kintana itself, except Concurrent Program
and Single Request Group Unit migration.