Professional Documents
Culture Documents
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:
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.
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.
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.
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.
1. Object Level
2. Project Level
3. Release level
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.
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
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.
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.
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:
B2 B3
Tag2
R1
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:
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.
Note: The code migration process will be done using the EME MC
(Management Console).
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.
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:
Page 8 of 13
AbInitio Configuration Mgmt V1.1
During this process, two possible scenarios might arise:
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.
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.
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
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.
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.
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.
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
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