Generic Integration and Release Approach Document_RTC_V2 0

Generic Integration and Release Approach Document

Slide 2

Version Date Description Author Reviewed by

0.1 25-06-2013 Initial draft Mushtaq Ahmed B

1.0 25-06-2013 Reviewed Shameem & Aswin

Document History

Slide 3

About this Document

Purpose This approach describes the high-level strategies and methodologies used to plan,

organize, and manage Integration and Release of Local developments (both Functional and Interfaces) through RTC (Rational Team Concert).

Terminologies Used

Abbreviation Description

L3 Local customization – Level 3

L2 Country Model and GPACK related – Level 2

CI Client Initiative

WI Work Item – Internal Defects raised by testing team.

IMP Implementation offsite Team

PACS Product Analysis and Customer Support

BCON Build Control – Consists of Development units: Data & Source or Objects

Ticket Customer log tickets to track the delivery.

BRD Business Requirement Document

FSD Functional Specification Document

Slide 4

Abbreviation Description

TSD Technical Specification Document

TAABS T24 Automated Analysis and Build System. A set of tools and procedures for capturing client requirements for central T24 parameters and the creation of a Model Bank T24 environment based upon them.

NCD Non-Core Development

ISB Initial System Build

Defect Defect will be associated with a ticket to track the status of the PACS fix.

Core PATCH Set of objects & data items given by the T24 Core product team as a fix for defects logged though the PACS ticket.

Customisation This defines the Functional and Interfaces that have been identified as Local Gaps

Static Data Refers to T24 Parameters, Customer, Account transaction

Financial Data T24 Transactions that generate Accounting Entries

TAM Updater Used to deploy change sets in the form of updates and the same is shared with the client for easier deployment

Slide 5

Introduction

This Document covers the Integration, Packaging and Release Management activities carried out by the Integration Team (IPRM), mainly aims to create required environments for the all projects with its required Operating System, Integrating the required development components in multiple environments through RTC and troubleshoot issues faced, if any, Maintaining delivered components in RTC Regression project area and Releasing these components to the Client in the form of TAM Updates.

Slide 6

RTC

RTC is a single system which integrates

Project plan Source control system Time tracking Development activities Reports Auto code review Deployment of change set in the desired environments.

Slide 7

IPRM

The objectives of IPRM are as follows:

To establish a common understanding on how to create and maintain various environments.

To troubleshoot deployment and integration issues. To maintain and control source codes and other components. To manage the releases delivered to the Client.

General Process is as follows for IPRM in RTC:

Project Manager/Delivery Manager will create a top level Work Item normally called as CI (Client Initiative) which holds as the parent for all subsequent Work Items.

Developers (Technical leads) will create a development Work Item under which different tasks from “Dev-BRD analysis” to the “Dev-Project management” – a final status after “Dev- Packaging and Delivery” is created. Here the development WI acts as a parent for all the Task WIs’.

Once the developments are done, developers will review the code which is automated on RTC (pre-check of codes) and if found any issues then those have to be cleared before moving to unit testing.

Slide 8

IPRM

Then, the status of “Code Review” or “Code Review Rework” should be in completed status for the testers to start the deployment and testing. Testers are responsible to deploy the packs in the testing environment with the help of RTC and if any failures on functionality will have to be reverted to the Developers. Deployment will also highlight the code review issues, if any. In case of deployment issues, IPRM will come into picture to solve the same.

Developers shall fix the issues raised by the testers through including or excluding the change sets in the work item.

Once the particular WI passes through the deployment activities and subsequent passing of testing, the WI will be moved to “Documentation review” or “Documentation rework” where PQC team will attach TCR and UG documents in the RTC.

For developments, on attaining the documentation rework as completed status, IPRM will come into picture for releasing the change set to the Client.

For PACS issues, Ticket should be in Maintenance and Defect should be in Integration status in RTC for IPRM to proceed with the delivery. IPRM uses a query to fetch all items that are ready for the delivery based on the above said status.

Slide 9

Environmental Creation

Before the above process gets started, the concerned DM or the Project lead has to request for L3 and L2 related environment creation with L3 DEV ENV TEAM. The below embedded is the request form in which all the required and necessary details has to be filled for its creation.

L3Dev_Environment Management_Form

Slide 10

Core Parameters

There are few core parameter tables available in T24 that should not be amended through BUILD.CONTROL tool or DL.DEFINE application. Deployment of core parameters will be restricted by RTC deployment process however the below process shall be followed if there are any requirements to change the core parameters.

Parameter Change Request (PCR)

Generally, any changes to the core parameters records in the T24 system also required a change set in RTC which will be integrated on to the Master environment.

PCR_(Project Name)_(Reference Number)_yy

Slide 11

Parameter Changes

Offsite Parameter Change:

Development team to add this PCR document to SharePoint and share the link with IPRM to do the changes in all IPRM environments and this PCR document will be delivered to the client for doing the changes in client’s environments.

Onsite Parameter Change:

After doing the required core parameter changes in Client environments, Client has to send the PCR document to the Development team, which in turn have to be uploaded to SharePoint and the same has to be shared with IPRM to do the changes in all IPRM environments.

Slide 12

Core Parameters

Below is the list of core parameter that needs to be done manually through PCR document.

LIST OF PARAMETERS

AC.CONSOLIDATE.COND CONDITION.PRIORITY INTERCO.PARAMETER SC.PERF.PARAMETER

ACCOUNT CONSOLIDATE.COND LIMIT.PARAMETER SC.STD.SEC.TRADE

ACCOUNT.PARAMETER CQ.PARAMETER MD.PARAMETER SCPM.GROUP.CONDITION

ACCT.GROUP.CONDITION CURRENCY MG.PARAMETER SCSK.GROUP.CONDITION

ALT.SEC.PARAMETER DATES NOSTRO.ACCOUNT SCTR.GROUP.CONDITION

AM.FUND.FLOW ER.PARAMETER PM.PARAMETER SL.PARAMETER

AM.PARAMETER FD.PARAMETER REPO.PARAMETER SPF

AM.PERF.PARAMETER FRA.PARAMETER REVALUATION.PARAMETER

SWAP.PARAMETER

COLLATERAL.PARAMETER FT.GROUP.CONDITION SAFECUSTODY.VALUES SAFECUSTODY.VALUES

COMPANY FX.PARAMETERS SC.PARAMETER TFS.PARAMETER

TRANS.FUND.FLOW

Slide 13

Local Reference Table

The authority for creating and amending of any Local Table and Local Reference Table is always with IPRM to secure the synchronisation process across all the environments. So, any need of changes has to be requested through IPRM. On request, IPRM will make the necessary creations and amendments in the offshore environments and then provide the pack to the Onsite team along with the release for the respective development or fix.

Note:

For Projects below R10 as T24 Release:

Any LT requested by L3/L2/Region/Client, the ID shall be created with Sequence Number.

Slide 14

Local Reference Table

For Projects with R10 and above as T24 Release:

Any LT requested by L3 Development team shall be created with ID as L3.<shortname>.

Any LT requested by CMB team shall be created with ID as L2.<shortname>.

Note: For any Application if the count of Local Table goes beyond the threshold level of 10 then the additions have to come through an approval from the Design Review Team only. All existing projects will continue with its current naming conventions.

Attached below are the LRR request form and also the LRR control matrix.

LRR_(Project Name)_(Reference Number)_yy

Local_Reference_Field_Control_Matrix_(Pr

Slide 15

Browser Configuration

Browser configuration and its troubleshooting issues will be done by IPRM for the Testing environment alone.

Development team will take care of their environment.

Core Updates

Core Updates will be synchronized on the Testing, Staging and Master

Environment based on the confirmation received from Development Team on its successful installation.

Client shall download the same from TCSP portal directly and sync their environments.

Slide 16

General SDLC

Slide 17

Delivery Approach

Offshore Methodology Workflow

There are three types of delivery approach that IPRM maintains which are as follows

Major Release Minor Release Emergency Release

Slide 18

Delivery Approach

Major Release:

IPRM delivers the Major release build (as a “bnk” (Application) and “oracle dump” (Database)) with the supporting document on how to install the same upon successful completion of testing. This will be delivered to client via FTP Server or by IPRM Portal. The directory structure of this initial release will be as follows,

Software Package: Software package will contain the Oracle dump, Bnk backup of the Master environment prepared by IPRM, and the Release notes containing the list of developments included in the release. This build holds all the signed off developments by the Project quality control team. Using the database import document, the Oracle dump can be restored in the Client’s environment.

Documentation: Documentation part covers the Installation Guides, Functional Specification Documents (FSD) and the Testing documents of all the signed off developments. Release Notes holds all the information related to the deliverables.

Slide 19

Delivery Approach

Minor Release:

Once the Master release is made, Client enters into the testing (SIT/UAT) phase where any bug fixing/changes has to be routed via IPRM and there comes the Minor release concept.

All the bugs fixed and tested over the month/fortnight will be packaged and delivered in the form of TAM updates on the monthly/fortnightly based upon sign off/Integration status via FTP or IPRM portal.

Note: The release of TAM Updates is only for the new projects and for projects which are already in implementation/support phase which migrated from the SVN will be delivered in the form of BCONs itself. There will be two BCONs delivered, one for Source and another for Data Records. All other source control process will be same for both the old and new projects.

The packaging process will be consolidation of all the fixes, LT/ LRT package (to ensure sync in Local fields) and an Installation guide containing all the Pre/Post installations, if any, and the order of deployment of the packages will also be included.

Slide 20

Delivery Approach

Emergency Release:

This release will be done in case if client needs an urgent fix for any show stopper issue and the same will be delivered to the Client in the form of TAM update. This also has to go for an approval process from the RDH.

Slide 21

Release Approach

Week 1st Week 2nd Week

Team Monday-Friday Monday Tuesday Wednesday Thursday Friday

L3 DEV

Development/Defect Fix




Code Freeze for the fortnightly’s delivery by Thursday COB

Development/Defect Fixing for subsequent release

TESTDeploy package for PQC Testing & Signoff

Deploy package for PQC Testing & Signoff




Deploy package for PQC Testing & Signoff for subsequent releases

IPRM Troubleshooting any deployment issues

Troubleshooting any deployment issues




Preparation of Consolidation package for fortnightly Release and delivery to Client via FTP server/IPRM Portal by IST COB.

Slide 22

Delivery Note

This document has to be included with all the Development and CR

deliveries and the Client acknowledgement has to be obtained after the delivery is made by the Delivery Managers. Attached is the Delivery Note template.

Delivery Note LOC Template

Slide 23

Release Notes

IPRM internally maintains a spread sheet which will have the track of all

the delivered items via IPRM. Below embedded is the sample for reference.

Project Mnemonic_Release Notes

Slide 24

Environments

Name Description Location

Initial System Build Offsite After the TAABS analysis is completed, the defined T24 parameters are loaded into the BSB (Base System Build) and the ISB process is run on to create the Initial Implementation environment.

Development Offsite As the name suggests the development activities are carried out here.

Testing environment Offsite These are environments used for Unit and Functional testing.

Staging environment Offsite All NCD components – Source Codes and Data Records that are passed the testing are promoted to this environment through RTC. Tam Updates are created from this environment.

Master environment Offsite The Tam Updates created from staging environment is released in this environment before releasing to the Client to check the deployment issues.

THANK YOU