You are on page 1of 13

AbInitio Configuration Mgmt V1.

AbInitio
Configuration Management V1.1

Page 1 of 13
AbInitio Configuration Mgmt V1.1

INDEX

1. Objective .................................................................................................................. 3
2. Definition -- Configuration Management (CM).................................................... 3
3. Background ............................................................................................................. 4
4. General Principle .................................................................................................... 4
5. Subject Areas........................................................................................................... 5
5.1 Tagging .......................................................................................................... 5
5.2 Code Migration ............................................................................................ 6
5.3 Common projects........................................................................................ 7
5.4 System Test/Pre-Prod defects................................................................. 8
5.5 EBFs & hot fixes......................................................................................... 9
5.6 Remedy Tickets ......................................................................................... 10
6. Parallel Development............................................................................................ 10
7. Roles & Responsibilities........................................................................................ 11
8. Access control........................................................................................................ 12
9. Abbreviations......................................................................................................... 13

Document History:

Date Version Description of Change Author


07/12/2008 1.0 Initial Draft Jyoti Ghosh
20/12/2008 1.1 Review comments incorporated from Jyoti Ghosh
TEG & AbInitio Software.

Page 2 of 13
AbInitio Configuration Mgmt V1.1
1. Objective
This document will describe the new configuration management process that
will be followed within the AbInitio area and will thus serve as a handbook for all
configuration management activities that need to be implemented in the current
context and future. This new process has been established considering all
current scenarios, existing problem definitions within the AbInitio area and best
practices suggested by AbInitio Software Limited. As part of configuration
management this document will also define ownership of processes and access
control to various environments.
This is an evolving document and any new changes/modifications to the
configuration management process will need to be updated in this document.

As part of the configuration management process the following subject areas


will be covered:

1. Tagging.
2. Code Migration.
3. Common Projects.
4. System Test/Pre-Prod defects.
5. EBFs & hot fixes.
6. Remedy Tickets.
7. Parallel development of projects.
8. Roles & Responsibilities.
9. Access control in different environments.

The AbInitio EME (Enterprise Metadata Environment) is used as the code


repository & configuration management tool within the AbInitio area.

2. Definition -- Configuration Management (CM)


CM is a "set of activities designed to control change by identifying the work
products that are likely to change, establishing relationships among them,
defining mechanisms for managing different versions of these work products,
controlling the changes imposed, and auditing and reporting on the changes
made." -- Wikipedia

Within the AbInitio area work products will refer to graphs (.mp), scripts (.ksh),
Sql (.sql), data manipulation language (.dml), transform functions (.xfr), project
parameters (.air-project parameters) etc

Page 3 of 13
AbInitio Configuration Mgmt V1.1
3. Background
In the current AbInitio world, configuration management is done using the
AbInitio EME. There are 4 instances of EME one in each of the environments
Dev, System Test, Pre-Prod & Production. Development is carried out in an
individual users sandbox and code is checked into the Dev EME which then
gets migrated to the next environments.

Dev EME Sys Test EME Pre-Prod EME Prod EME

Development System Test Pre-Prod Production

Sandbox1 Sandbox2
Sandbox1 Sandbox2 Sandbox1 Sandbox1

Sandbox3

Check-in code in EME from Sandbox Check-out code from EME to Sandbox

4. General Principle
As a principle every development project will be coupled to a Release. This
decision will be made when a project plan has been established by the
respective Project Manager in conjunction with the Release Manager.
Configuration management will be carried out and monitored via the AbInitio
EME.

Going forward EME branching will be the basis of all new developments in
AbInitio -- small or big. No developments will happen on the main Trunk and it
will always be a replica of the Production code. Whenever a release is
implemented in production it will create a new production baseline code which
will then be refreshed back to the main development trunk thus moving the
development trunk baseline by one step and at par with production. Any
subsequent development coming along will then branch out from the new code
baseline. In the event where a branch is still on development and there is a new
production baseline, the development branch will retro-fit any common code
that the branch is working on which is a part of the new production baseline.
Branches will be deleted whenever its thought to be of no further use.

Page 4 of 13
AbInitio Configuration Mgmt V1.1

The concept of a Trunk & EME Branches is analogous to a Tree which has a
main trunk and several branches. Fig 1.1 illustrates the same:

Branch2 = Project2

Branch1 = Project1

Main Trunk

Fig 1.1

During the project kick-off meeting the EME administrator will be notified about
the new project who will then create a branch for the new project in the EME
and communicate the same to all stake holders.

5. Subject Areas
5.1 Tagging

Tagging is another name for labelling with respect to AbInitio. It defines a way
of identifying different versions of a single or multiple pieces of code that
resides in the code repository.

Tagging of code will be done at three levels:

1. Object Level
2. Project Level
3. Release level

Object Level Tag

An object refers to an individual piece of code like .mp, .ksh, .dml, .xfr, .sql etc
Considering that one or many developers will be working on a project and
possibly on one or multiple objects, they will apply object level tag when code is
checked into their respective branch in the EME via the GDE.

Format of object level tag: <OBJ_BRPNO_current date_time>


E.g. OBJ_60225_20081124_1130

The object level tag is purely for the developers benefit to help them identify
different versions of the object in the code repository giving them flexibility to go
back to any versions.

NB: The standard process of checking out a project from the EME into each
developers sandbox and locking it for modification remains the same.

Page 5 of 13
AbInitio Configuration Mgmt V1.1
Project Level Tag

Here Project refers to an EME project which is a collection of graphs (.mp),


deployed scripts (.ksh), data manipulation language (.dml), transformation
functions (.xfr), Sql files (.sql).
On completion of the final build phase the developers will pass on all the latest
object level tags to the Development Lead of the project who will then combine
all of them into one project level tag consisting of everything for the project.

This project level tag will form the basis of QA for the Analysis & Architecture
team as well as code migration from Dev to the next environment.

Format of project level tag: <PROJ_BRPNO_current date_time>


E.g. PROJ_60225_20081205_1230

Release Level Tag

Release level tag will be a combination of all project level tags which form part
of a Release. The EME administrator will collate all the Project level tags into
one Release Tag which will be the basis of migrating code from one
environment to another.

Format of Release Tag: REL1_Jan_20080120_1635

5.2 Code Migration

Code migration from one environment to another will be done via EME MC and
this will be complemented by Tagging as defined in section 3.1. Code migration
will follow the path of EME to EME i.e. the sequence will be as:

Dev EME System Test EME Pre-prod EME Prod EME

Fig 1.2 illustrates the same.

Dev EME System Test EME Pre-Prod Prod


Tag1 R1 R1
B1
R1

B2 B3
Tag2

R1

Code Baseline Fig: 1.2


Release Branch

Page 6 of 13
AbInitio Configuration Mgmt V1.1
As part of development each project will be on a different branch and will have
its own project level tag defined. Upon completion of the build phase the
development lead of the respective project will pass on the project level tag:

1. First to the A&A team for code review.


2. On successful completion of code review & sign-off the latest Project level
tag will be passed on to the EME admin for code migration.

EME admin will combine all the project level tags (Tag1 & Tag2 as shown
above) for that release into one release tag (R1). These combined tags will
then be put in a Release Branch from where the code will be migrated from
dev to the system test/Pre-prod & Prod environment.

Once the release branch is created, the development leads should confirm all
the changes and any new objects present in the release branch. Upon
confirmation of the release branch, the code will be migrated from dev to the
system test/pre-prod and Prod environment.

The Configuration Manager/Release Manager in conjunction with the Lead


Developer

Note: The code migration process will be done using the EME MC
(Management Console).

5.3 Common projects

Common projects refer to EME projects which are linked to every project --
public or private within the EME. These common projects contain a number of
generic defined variables which are inherited by other projects when included
(linked) within them. Any change to these common projects has a wider impact
to all other projects within the environment. The common projects within the
current AbInitio environment are:

1. Local Environment
2. Stdenv
3. Tools
4. PSD Schema
5. All source system schemas.
6. Mart Schema.
7. Investment Mart Schema.

As part of configuration management the following process & rules apply to the
common projects listed above:

1. There will be one single owner for all the common projects and no one will
have access to check-in a common project in the EME.

Page 7 of 13
AbInitio Configuration Mgmt V1.1
2. A single sandbox for common projects in the development environment
which every project will link to.
3. Change request for any common projects will be via the owner of common
projects.
4. A&A team/Dev Leads of respective projects to do upfront analysis for any
change to common projects and communicate the same to owner of
common projects.
5. Owner of common projects to do an impact analysis (via the EME) of all
affected components and communicate the same to all in-flight projects
impacted.
6. Tagging of common projects will be done by the owner of common projects
as part of a release. This tag will be passed on to the EME admin for
migrating the common project from one environment to the other. This tag
will also form part of the same release and will be collated by the the EME
administrator.
7. When two projects are in parallel development and changing common
projects using different sandbox, two scenarios may arise:

a. Both projects form part of the same release In this case one of
the projects has to merge the changes of the other before release.
Conflict items can be highlighted using specific functions in the EME
code in each tagged branch. If conflict exists both teams will work
together to reconcile the differences and unit test each branch
simultaneously.
b. Both projects are not part of the same release In this case the
later project has to retro-fit the changes of the former project before
release.

5.4 System Test/Pre-Prod defects

Every development project in its life cycle has to pass through System Test &
Pre-Prod environment before it goes to Production.

Here System Test / Pre-Prod defects refer to functional & code defects in the
System Test and Pre-prod environment during system test & pre-prod run
execution. Considering that each project will be on an EME branch, the below
will be the process for fixing & migrating system test/pre-prod defects when
encountered is:

1. Developers responsible for defect will go back to their respective EME


branch in the Development environment, fix the defect and apply object
level Tag/s for each individual object. These tags will be passed on to the
development lead of the project.
2. Development Lead will re-tag the whole project in the EME branch as a
project level tag and pass on the same to EME admin for migrating it to the
system test/Pre-prod environment.

Page 8 of 13
AbInitio Configuration Mgmt V1.1
During this process, two possible scenarios might arise:

a) The object/s being fixed are now being worked on by a different


project In this case the project which is in system test will inform the other
project about the fix which the later has to retro-fit.
b) The object/s being fixed are independent of any changes being made
by a different project In this case this will a straight fix on the EME
branch and promote to the next environment.

5.5 EBFs & hot fixes

EBF & hot fixes refer to defect fix in Pre-prod & Prod environment and applies
to users who are on on-call support. These fixes normally happen during the
overnight.

The process to follow for EBFs & hot fixes is:

1. The object being fixed will be locked in the Production EME against the
main trunk.
2. Apply fix for the batch/operation process to continue.
3. Next day, the on-call person to communicate the fix to all.

Two possible scenarios:

a) The same object/s are being worked on by a different project in


the development environment On-call person to liaise with the
development team to retro-fit the changes made as part of project
development and form part of a release.

b) The same object is not being worked in the development


environment On-call person will lock the code against the
development trunk, apply the changes and check-in the code in the
development trunk using object level tag. This tag will be passed on
to the EME admin to migrate the object to all the environments. This
will ensure that the object is in sync in all the environments.

Format of object level tag for EBFs: <OBJ_EBF_INCNO_current date_time>


E.g. OBJ_EBF_INC12345_20081205_1230

Note: The on-call person will not check-in any code in the Production EME.

Page 9 of 13
AbInitio Configuration Mgmt V1.1
5.6 Remedy Tickets

Remedy tickets refer to problems/defects in production environment which are


normally raised by the business users as they do their daily/monthly reporting.
These remedy tickets are dealt with by the Application Support team.

For remedy tickets the following below will be the process:

1. The production version of the code will be checked-out from the main trunk
of the development EME by the EME admin and put on to an EME branch
for the application support user to analyse/work.
2. The Application support user will work on the respective branch and the
remedy ticket will form part of the normal release cycle i.e. the code will
from part of a release and will be migrated through the various
environments undergoing appropriate test cycles.

Two possible scenarios:

a) The same object/s are being worked on by a different project in


the development environment In this case it will be considered
as another parallel development instance and depending on who hits
the release cycle first, the later will have to retro-fit the changes of the
former.
b) The same object is not being worked in the development
environment In this case the remedy ticket will follow the normal
development work stream i.e. it will form part of a release and will be
migrated through all the environments under going appropriate test
cycles.

6. Parallel Development
Parallel development refers to situation where two or more projects contend on
one or more objects for a change. Parallel development within the AbInitio area
will be done using EME branching. During analysis phase of a project by
Analysis & Architecture Team it will be determined whether projects have code
contention.

The following principles will apply for parallel development:

1. EME admin to be notified to create branches during project start-up.


2. Projects which are in parallel development will do this work on
different EME branch.
3. EME branch will be created based on the most recent production
code baseline.
4. Respective Project Managers of the projects to manage contingency
with respect to code merging.
If the projects in parallel development form part of the same release,
one of them will merge with the other before migration to the next
environment. The decision of who merges will be determined by the

Page 10 of 13
AbInitio Configuration Mgmt V1.1
amount of change involved in each project. The project with less
change will be a candidate to merge i.e. the project undergoing more
change to common objects will incorporate the lesser changes. The
development leads would interact with each other and decide who
will merge the code based on the volume of change.
5. If the projects in parallel development form part of a different release
then the later has to merge its code with the former before migration
to the next environment.

7. Roles & Responsibilities


The table below lists the roles & responsibilities/activities with respect to
Configuration management:

SL.No Role Activities


1. Configuration Manager 1. Overall governance of Configuration
management within AbInitio area.
2. Co-ordinate with the Release Manager and
ensure in proper bundling of the release.
3. Co-ordinate with different stake holders of
projects and communicate any
discrepancies as appropriate.
2. EME Admin 1. Creation of EME.
2. Maintenance of EME (clean up, purging
etc)
3. Creation of projects in the EME (private &
public).
4. Access control for different categories of
users (developers, development leads,
A&A team, App. Support person,
Business)
5. Code Migration between environments.
6. Building releases for System test/Pre-
prod/Prod environments.
7. Any installation/upgrade activity of EME.
8. EME branch management.
9. Governance to Tagging of Projects at
project level/Release level.
3. Common project owner 1. All changes to common projects.
2. Maintenance of common projects.
3. Impact assessment with respect to
changes in common projects.
4. Standards & best practices to be followed
for changes to common projects.
5. Tagging of common projects for releases.
4. Developers 1. Tagging of individual objects as per
convention.
2. Check-in code to the development EME.
3. Aid development leads by passing on
latest object level tags.
5. Development Leads 1. Collate all latest object level tags to build
a Project level tag.
2. Pass on relevant Project level tags to EME
admin for code migration.

Page 11 of 13
AbInitio Configuration Mgmt V1.1
3. Governance to tagging of objects by
developers.
4. Decide who is responsible to merge the
code if the projects in parallel
development form part of the same
release

6. Analyst/Architect 1. Governance to overall tagging (project


level) prior to code migration.
2. Sign-off for code migration.

8. Access control
A successful configuration management entails proper access controls within
various environments.

The following table lists who will have control where based on individual
roles:
Sl. No. Role Access
1. Everything within all instances of EMEs.
2. All environments (dev, Sys Test, Pre-prod
1 EME Admin
& prod.
3. EME MC.
2 Developers 1. Private sandbox
2. Dev EME only for check-in/check-out of
code.
3. Dev Environment
3 Development Leads 1. Private sandbox
2. Dev EME only for check-in/check-out of
code
3. Restricted access to Dev EME for tagging
of code at project level via the EME MC.
4. Dev Environment
4. On-Call Support 1. All environments( Dev, Test, Pre-Prod,
Prod)
2. Full Access to Dev EME.
3. Restricted access to Pre-prod & prod for
EBFs i.e. no check-in access to pre-
prod/prod EME.
5. App. Support 1. Dev EME
2. Dev Environment
6. Analysts/Architect 1. Dev Environment
2. Dev EME
7. Common Projects 1. Dev EME
Owner 2. Dev Environment
3. Full access to all common projects in the
Dev environment.

Page 12 of 13
AbInitio Configuration Mgmt V1.1

9. Abbreviations
EME Enterprise Metadata Environment
EME MC Enterprise Metadata Environment Management Console
EBF Emergency bug fix
A&A Analysis & Architecture
CM Configuration Management

Page 13 of 13

You might also like