FUJ00232666
FUJ00232666
oO Release Management Strategy
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Document Title: Release Management Strategy
Document Reference: SVM/SDM/PRO/1520
Release: N/A
Abstract: This document details the Release Management strategy at a high
level.
Document Status: Approved
Author & Dept: Dan Whitman, Release Management
External Distribution: NO
Security Risk YES
Assessment Confirmed
Approval Authorities:
Name Role See Dimensions for record
Alan Flack Operational Change & Release Manager
Tony Atkinson Head of Release Management
See HNG-X Reviewers/Approvers Matrix (PGM/DCM/ION/0007) for guidance on who should approve.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIALIN _ Ref. SVMI/SDM/PROI1520
CONFIDENCE) Version 1.0
Uncontrolled if Printed or Distributed Date 26/01/2015
Page No: 1 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
0 Document Control
0.1 Table of Contents
0 DOCUMENT CONTROL.
0.1 Table of Contents.
0.2 Document History.
0.3 Review Details..
0.4 Associated Documents (Internal & External
0.5 Abbreviations.
0.6 Glossary...
0.7 Future Changes Expecte
0.8 Accuracy.....
0.9 Security Risk Assessment
0.10Requirements Acceptance Activi
2 RELEASE TYPES.
2.1 Major Releases.
2.2 Emergency fixe:
2.2.1Operational changes 14
2.3 Maintenance Release:
2.3.1Maintenance Release planning rules 15
2.4 POLMI and POLSAP releases...
2.4.1SAP Transports
2.5 Release Independent Releases...
2.5.1Reference Data Test releases
2.5.2Security patching
2.5.30perational changes
2.5.4Platform builds / rebuilds
2.5.5Common Products
2.5.6Backlog
3 RELEASE PLANNING...
3.1 Release Planning...
3.1.1RP Objectives —- 6 Week Release Plan (Tuesday meetings)
3.1.2RP Objectives - Upcoming Release Plan (Thursday meetings)
3.1.3RP Attendees
3.1.4RP Inputs
3.1.50utputs
3.2 Business Impact Forum (BIF) & PEAK Targeting Forum (PTF).
3.3 Quality Filtering Process (QFP)....
4
4.1 Maintenance Release Schedule...
4.2 Forward Schedule of Change (FSC) for Atos / PO!
4.3 Release Deployment plans.
4.3.1High level deployment plans 26
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIALIN _ Ref. SVMI/SDM/PROI1520
CONFIDENCE) Version 1.0
Uncontrolled if Printed or Distributed Date 26/01/2015
PageNo: 2 of 43,
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
4.3.2Detailed deployment plans
4.4 Deployment Plan Walkthrough.
5 RELEASE CONTENTS.
5.1 Major Release contents....
5.2 Maintenance Release contents..
5.2.1Change Proposal inclusion
6 RELEASE TOOLING.
6.1 Dimensions.
6.2 Peak.....
6.3 Release Schedule. 34
6.3.1Baselines 31
6.11Release Note:
6.12Release Deployment Plan.
6.13Bill of Materials (BOM)..
7 MONITORING OF THE END TO END METHODOLOGY.
7.1 Key Performance Indicators...
7.1.1Major Release Key Performance Indicators
7.1.2Maintenance Release Key Performance Indicators
7.1.3Security patching Key Performance Indicators
8 ROLES AND RESPONSIBILITIES.
8.1 Release Management... eee 3D
8.1.1Head of Release Management 35
8.1.2Release Management Team Manager 35
8.1.3Major Release Manager 35
8.1.4Maintenance Release Manager 35
8.1.5Release Planner 36
8.1.6Release Controller 36
8.1.7Peak Targeting Forum Administrator 37
8.2 Development..
8.3 Integration.
8.6 Architect..
9 APPENDICES.
9.1 Appendix 1 - Deployment Groups.
9.2 Appendix 2 - Cloned Peaks...
9.3 Appendix 3 —- Release numbe!
9.3.1Major Release
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 3 of 43
FUJ00232666
FUJ00232666
oO Release Management Strategy
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
9.3.2Maintenance Release 40
41
9.4 Appendix 4 - Release planning facilities / dates in Peak.
9.5 Appendix 5 — Baseline inclusion in a releas:
9.6 Appendix 6 — Fault Peak Lifecycle...
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Date: 26/01/2015
Uncontrolled if Printed or Distributed
PageNo: 4 of 43,
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
0.2 Document History
Version No. Date Summary of Changes and Reason for Issue Associated Change -
CP/PEAK/PPRR
Reference
01 5/1/2011 Initial version
02 13/2/2011 Updated version
03 20/2/2011 Updated following review
04 23/6/2011 Updated for review
05 29/9/2011 External Review inc. Comment Updates
06 05/10/2011 Post Internal Team Review inc. Comment Updates
07 20/8/2014 Updated document to bring in line with current processes and
procedures
08 26-Jan-2015, Updated with changes following review of 0.7
1.0 26-Jan-2015 _I Approval version
0.3 Review Details
See HNG-X Reviewers/Approvers Matrix (PGM/DCM/ION/0001) for guidance on completing the lists below. You
may include additional reviewers if necessary, but you should generally not exclude any of the mandatory
reviewers shown in the matrix for the document type you are authoring.
Review Comments by
Review Comments to Dan.Whitmang J
Mandatory Review
Role Name
Head of Release Management Tony Atkinson
Release Management Team Manager Alan Flack
Head of Test Mark Ascott
Integration and SCM Manager Vijesh Pandya
Senior SCM Specialist Dave Pooler
Head of Post Office Transformation Service lain Janssens
Principal Technical Services Specialist ‘Andrew Gibson
Principal Technical Services Specialist Paul Stewart
Technical Services Specialist Ryan Hawkes
Role Name
Operations Director Pete Thompson
Application Development Manager Keith Tarran
Problem Manager Steve Bansal
Test Manager Chris Maving
© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
PageNo: 5 of 43,
FUJ00232666
FUJ00232666
oO Release Management Strategy
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Lead SDM & Risk Manager Yannis Symvoulidis
Release Manager Sarah Payne
Release Manager Julia Betteley
Release Manager Adam Sobot
Release Manager John Budworth
Release Planner Louise Barham
Release Controller John Boston
Release Controller Lorraine Elliott
Operational Change Manager Nina Brickell
Quality and Compliance Manager Bill Membery
Business & Change Manager Ken Westfield
Document Manager Matthew Lenton
Requirements Analyst Steve Evans
Senior Operations Manager Alex Kemp
PMO Manager Mark Arnold
SSC Manager Steve Parker; SSC Duty Manager
Architect Pete Jobson
(* ) = Reviewers that returned comments
0.4 Associated Documents (Internal & External)
Reference Version Date Title Source
DEV/GEN/SPE/0007 Latest Latest Platform Hardware Instance List Dimensions
DEV/INF/POL/0753 Latest Latest Platform upgrades and outage Dimensions
PA/STR/003 Latest Latest Fujitsu Services Release Policy PVCS
SVM/SEC/POL/0003. Latest Latest Information Security Policy Dimensions
PGM/CM/PRD/0001 Latest I Latest HNG-X Software Configuration Management Dimensions
Process Definition
SVM/SDM/PRO/1184 Latest Latest MSC Managed Service Change Procedure for Dimensions
Post Office Account
SVM/SDM/STD/2593 Latest I Latest Terms of Reference for POA BIF and PTF Dimensions
DE/PRO/O15 Latest Latest POA Systems Integration Directorate Incident / I Dimensions
Defect Management
PGM/CHM/MAN/0002 Latest Latest Change Management Instructions Dimensions
CSMANOO1 Latest I Latest I Peak User Guide Dimensions
PGM/CM/STD/0001 Latest Latest Dimensions Naming Standard Dimensions
DEV/GEN/SPE/0007 Latest Latest PHIL
PGM/CHM/PRO/0001 Latest Latest Change Process Dimensions
SVM/SDM/WKI/2689 I Latest I Latest Release Management Deployment Plan Work I Dimensions
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIALIN _ Ref. SVMI/SDM/PROI1520
CONFIDENCE) Version 1.0
Uncontrolled if Printed or Distributed Date 26/01/2015
Page No:
6 of 43,
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
I [ Instruction
Unless a specific version is referred to above, reference should be made to the current approved
versions of the documents.
0.5 Abbreviations
Abbreviation Definition
BAL Branch Access Layer
BC Business Continuity
BCP Business Change Proposal
BDB Branch Data Base Server - Main
BDS Branch Data Base Server - Standby
BIF Business Impact Forum
cP Change Proposal
DG Deployment Group
DPVB Deployable Product Version Baseline
E2E End to End
KEL Known Error Log
KPI Key performance indicators
LsT Live Support Test (a test rig and team of people who use the rig)
Msc Manage Service Change
PAB Patch Approval Board
PAF Postcode Address File
Pcl Peripheral Component Interconnect
Peak Fujitsu services incident and release management system. Also used to describe a
record (defect) raised within the Peak system
PHIL Platform Hardware Instance List DEV/GEN/SPE/0007
PLD The Development environment where customizing and development can be
performed by Fujitsu
PLE The Test/Training ‘isolated’ environment for Post Office to test end-to-end
functionality of the SAP solution. Authorisation for import of change into this system
and all of its clients is the responsibility of Post Office following recommendation by
Fujitsu Services
PLP The stand-alone production environment for Post Office End-users. Authorisation
for import of change into this system and all of its clients is the responsibility of Post
Office following recommendation by Fujitsu Services
PLQ The QA ‘isolated’ environment for Fujitsu to test customizing and development
changes for integration and quality assurance. Authorisation for import of change
into this system and all of its clients is the responsibility of Fujitsu
PM Project Manager
POA Post Office Account
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIALIN _ Ref. SVMI/SDM/PROI1520
CONFIDENCE) Version 1.0
Uncontrolled if Printed or Distributed Date 26/01/2015
PageNo: 7 of 43,
FUJ00232666
FUJ00232666
oO Release Management Strategy
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
POL Post Office Ltd
POLMI Post Office Ltd Management Information (Credence)
POLSAP Post Office Ltd SAP.
PSPID Platform Set Platform Instance Definition. This is a set of baselines which are
delivered to the Data Centre for deployment
ac Quality Centre
QFP Quality Filtering Process
PTF Peak Targeting Forum
RDT SSC’s Reference Data Test Rig
RM Release Management
RMF Release Management Forum
RN Release Note. This is the form on Peak used to manage the release of baselines to
Test and live.
RP Release Planning
RS Release Schedule
scm Software Configuration Management
SSB System Software Baseline
SAP Systems Application Product
SV&l Solution Validation and Integrity
TEM Tivoli Endpoint Manager
TES Transaction Enquiry Service
TPM Tivoli Provisioning Manager
Tws TES Web Server
0.6 Glossary
Baseline backlog This is the set of baselines which have been delivered into Dimensions but have not
been deployed to Test or live
Baseline catch-up This defines the baselines which are in the baseline backlog and whether they are to
be taken with a release
Collection This is used to describe the grouping of Peaks (usually a default set of characters
such as “RP-Release_Planning’)
Common Products A common product is a baseline that is to be applied across all platforms within an
operating system type (e.g. Windows) and is contained within the common product
‘stack (this can be viewed within Dimensions via workset
SCM_PLATFORM_ATTRIBUTES_NA, selecting ScmPlatformStack_WIN etc). It is
not to be confused with a baseline that is applicable to more than one platform type.
Deployment Group ‘A Deployment Group (DG) is a set of platforms which can be upgraded in isolation
from any other platform. Maintenance Releases are scheduled to include one or
more DGs.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIALIN _ Ref. SVMI/SDM/PROI1520
CONFIDENCE) Version 1.0
Uncontrolled if Printed or Distributed Date 26/01/2015
PageNo: 8 of 43,
FUJ00232666
FUJ00232666
oO Release Management Strategy
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Stack of baselines This is a set of baselines which have been grouped together to be deployed by TPM
as a set.
Superseded status In Dimensions a baseline can have a “DPVB_Status” set to “superseded”. It should
not be deployed to the target platforms if a later version for the same release is
available and will be deployed OR a later version for a later release is available and
will be deployed
0.7 Future Changes Expected
Changes
Section 2 need more details about releases being deployed to RDT
Add detail to 2.3.3 once the POLSAP release process is agreed. POLSAP Team to provide us with their process
document.
LST need to know about SVI - Add to release planning spreadsheet, ask SP.
Currently no outputs from QFP, QFP TOR needed, but not in this document.
Changes to Flowcharts in section 2
Counters/PVCS section needed as area not covered by any other sections
Multi DG section needs to be created
Table of tools needs revisiting to accurately reflect how they are used in the process
Section needed for PVCS
Section needed for TEM
Frequency for deployment groups needs to be reviewed
Other comments to be addressed from SCM SSC and Business change
0.8 Accuracy
Fujitsu Services endeavours to ensure that the information contained in this document is correct but, whilst every
effort is made to ensure the accuracy of such information, it accepts no liability for any loss (however caused)
sustained as a result of any error or omission in the same.
0.9 Security Risk Assessment
Security risks have been assessed and it is considered that there are no security risks relating specifically to this
document.
0.10 Requirements Acceptance Activity
POLNFRDR InternalFS POL Document Document Section Heading
Acceptance Ref NFRReference — Section Number
SER-2194 SER-2148 4 Future Release Mechanism
© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVMISDMIPRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 9 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
1 Purpose
This document details the Release Management strategy at a high level. It is backed up by a high level
E2E Release process flowchart and a set of Work Instructions which are held in SharePoint.
2 Release types
The release policy is based on customer requirements and requests for change. The approach is.
dependent on the size and nature of the affected systems, the number and frequency of releases
required, and any special user requirements that need to be prioritised.
Software Releases to the Post Office HNG-X environments are divided into three main types as shown
below.
Major Releases Maintenance Emergency
Releases fixes
J <
I
£ x i
DG POLMI / POLSAP. RDT
Platform builds / rebuilds Operational changes
1. Major Releases (frequency every 6 to 12 months) — these are managed by the Post Office Account
Programme Team and will normally deliver significant new functionality, scheduled with
understanding of the requirements of the customer. There are three or four major releases during a
year. A Major Release may contain one or more of the following types of change:
« Change(s) to business functionality requested by the customer (including a new service)
e — Infrastructure changes (including major changes)
« Non-critical fault fixes
e Service level improvements.
2. Emergency fixes (frequency as required) — these are applied estate to resolve operational issues.
3. Maintenance Releases (frequency every 6 to 8 weeks) — these usually do not add significant new
features or content, and are applied to address minor problems or security issues. These are applied
frequently and there may be twenty or thirty between each Major Release. A Maintenance Release
may contain one or more small changes implemented between Major Releases:
e — Service improvements
© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/1520.
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 10 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
* — Non-critical fault fixes
e — Security enhancements/fixes
2.1 Major Releases
These are managed by the POA Programme Team and are scheduled as agreed with the customer.
Each Major Release slot will be given a release number in the format xx, where xx is the next sequential
Major Release number. For full details on release numbering see Appendix 4.
Major Releases are restricted to update only the platforms which are necessary to enable the
deployment of the new functionality. By default any baseline backlog is NOT taken with a Major Release,
though any common products as a result of the major release are deployed where possible to the whole
estate.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 11 of 43
FUJ00232666
FUJ00232666
oO Release Management Strategy .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN €
CONFIDENCE)
gq =
Meeting assigns
\. release number
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/1520.
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 12 0f 43.
FUJ00232666
FUJ00232666
oO Release Management Strategy “
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN €
CONFIDENCE)
2.2 Emergency fixes
© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/1520.
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 13 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Emergency fixes will only be applied for ‘A’ priority issues, fixes that need a baseline to be delivered by
Development.
«The Peaks will be targeted at the current live release for the DG to which the fix applies.
e The fix will be delivered as a single RN with the inclusion of no other Peaks / CPs or
baseline catch-up.
e The fix will be included in the next Maintenance or Major Release for the relevant DG.
e Fixes of this type can be released in parallel with other Maintenance and Major Releases.
Follows stanrd approach of PEAK raised, MSC rasied for testing, RN/notes rasied and tested, post
successful testing applied to RDT and or live under full MSC approval
2.2.1. Operational changes
Where an urgent change is needed to the live estate, these are documented and tracked in MSC and will
be applied and tested on LST before application to live.
Following application to live a call is raised which normally results in a Peak. This is passed to
Development for review and is then processed in the normal way for a formal baseline fix to gain
approval through the BIF / PTF and then included in a Maintenance or Major Release.
2.3 Maintenance Releases
Maintenance Releases can be split into a six different sub-types determined by area affected by the
release:
* DG Maintenance Release
* ~POLMI / POLSAP
e =RDT
© Operational changes
* Platform builds / rebuilds
© Security configuration — via a release independent process
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 14 of 43.
FUJ00232666
FUJ00232666
oO Release Management Strategy .
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Information on PEAK
When required KEL is raised by the SSC
2.3.1 Maintenance Release planning rules
There are currently 27 DGs which are groupings of platforms that normally have an inter-dependency
when updated, for example BDB baselines are normally applied to BDS. References can be found in the
PHIL which gives details of the DG for each platform.
There are a number of planning rules around the scheduling of Maintenance Release slots for DGs, as
follows:
e Each DG is allocated a Maintenance Release slot at least once a year
e The frequency of Maintenance Release slots for each DG will depend on the historic rate of
change. The current rules are in Appendix 4
e Each Maintenance Release slot will be given a release number in the format xx.nn where:
o xx relates to the Major Release
o nnis anumber with no sequence implications, starting at 10
For full details on Release numbering see Appendix 4
« Each Maintenance Release number and its associated content is treated as completely
independent of any other release
« Where DG releases are inter-dependent and must be deployed at the same time they will be
allocated the same Maintenance Release number
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: SVM/SDM/PRO/1520.
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 15 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e Before each Major Release we strive to ensure a multi DG release is scheduled to enable any
partially deployed and already tested common products to be deployed to their remaining target
platforms. However this is not always the case, if this happens common products are bundled
into the release due to time constraints
e The WEB DG must have a Maintenance Release slot so that a delivery can go live in April and
November each year. This is required to comply with CCN0921 (CP520) for twice yearly
changes to the Online Counter Training Web Service (platform OWS)
e The deployment to live must mirror the order in which Maintenance Releases are deployed to
LST as far as possible
e PV Drivers are deployed manually currently.
« New platform builds require updates to documents such as the PHIL, and this should be done
before the planning process to allow the appropriate impacting to take place.
e A platform rebuild needs clear working direction from Development as part of the delivery and it
is prudent to allow additional time for this when planning.
e Platform builds / rebuilds are assigned Maintenance Release numbers in the twice weekly
Release Planning meetings at which point the appropriate representative attending the meeting
will be tasked with assigning a Project Manager or work package manager. This will then be
recorded in the Maintenance Schedule.
e Assigning a new Maintenance Release number will result in the sending of a Target Release
Request Template.xis to the following mailboxes to create them in both Peak and Dimensions
("PostOfficeAccount SCM HNG-X" & “Peak DBA” )
« ATWS Schedule release must not overlap with a DATABASE DG release or another TWS
schedule release in LST
2.3.1.1. Maintenance Release timeline
Each Maintenance Release follows a timeline to track the delivery to live. This timeline is reflected in the
Maintenance Release plan and is as follows:
I Week Elapse Issue Addressed
I d days
I Week x Agree Maintenance Release slot and start targeting Peaks
I Week y Stop targeting Peaks (cut off date)
I +7 Development completed delivering all of their Peaks / CPs
I +14 Integration have processed all the deliveries
I +21 RM have a single RN plus PSPID with LST ready for use
I LST start testing
I Week z LST complete testing and sign off the release for live
+7 RM have a single RN and a PSPID with live ready for
deployment
Commence release to live
The timeline for counter changes is different to the above as it requires a change to a Data Centre
platform before the changes to the counter can be deployed.
2.3.1.2 Maintenance Release slot parallelism
There are a number of instances where DGs need to be combined into a single Maintenance Release.
These will be managed as part of the Release Planning meeting but some general rules apply:
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 16 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Counter App and BAL DGs will be scheduled to be delivered by Development in parallel and will have
the same Maintenance Release number.
DG SYSMAN3 will be scheduled to be delivered by Development in parallel but will have different
release numbers as they will be deployed separately. This scheduling restriction is to assist the
development unit.
CPs may require one or more maintenance slots to be combined and this will be managed as it becomes
known.
Security patch testing (excluding Anti Virus signatures) should not run in parallel with DATABASE DG.
testing.
2.3.1.3. DG Maintenance Releases
These are scheduled, by DG, by the Release Planning forum with the understanding of all the other
release streams.
The DGs have been agreed and are a subset of platforms on the HNG-X estate which can be upgraded
in isolation from all other platforms. The master list of DGs and their associated platforms is held in the
PHIL, however this is uploaded to both Peak and Dimensions. A report of DGs can be obtained from
Peak.
DG Maintenance Releases are scheduled in a number of ways depending on the circumstances:
« Anumber of DG Maintenance Releases, scheduled between Major Releases, are planned as a
set.
e At the request of the BIF / PTF forum, if there are Peaks to be resolved and no suitable slot
exists.
e At the raising of a CP which needs to be included in a DG Maintenance Release and no suitable
slot exists.
2.3.1.4 Multiple DG Maintenance Releases
Usually a fix for a single Peak or one or more CPs may need a change to multiple DGs. These changes
can have various properties and these properties necessitate different planning scenarios as follows:
« Changes where the fix needed to resolve the issue is contained in a single DG but the baseline
deploys to other DGs for completeness.
o Deploy to the DG which needs the fix to resolve the problem and deploy to the
remaining DGs as part of baseline backlog catch up
« Changes where the fix needed to resolve the issue completely has to be deployed across.
multiple DGs and MUST be deployed at the same time
o A Maintenance Release containing multiple DGs will be scheduled.
« Changes where the fix needed to resolve the issue completely has to be deployed across
multiple DGs but each part can be deployed at different times. In this scenario the change can
only be tested once the final deployment is made
o If this is known up front then a Maintenance Release containing multiple DGs will be
scheduled
o If this comes to light as a fix is delivered then the delivery will be made in different
Maintenance Releases.
co The first part to be deployed to the first DG will use the original Peak and will be tested
as benign
o Aclone Peak (or Peaks) will be raised to carry the changes to the later DG(s)
o The Peaks will be updated to ensure they are clear that the complete change cannot be
tested until the final DG is deployed
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 17 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
co This is the most complex scenario and, when deploying to the last DG, may necessitate
an urgent fix to one of the earlier DG deployments
Original pick
First part deployed to DG
Tested as
benign I
Clone pick
‘The changes are carriedto
the later DG(s)
Release planning meeting -release is
created and number is assigned p> pobien.
Sx Oe]
ee EDE
Clear updates ——> 2st 9G deployment
It would be possible to take a single emergency fix to a platform in parallel with a DG Maintenance
Release slot but this should only be done in exceptional circumstances or if a change is needed in order
for Test to approve the release for live.
2.4 POLMI and POLSAP releases
Changes to some DGs for HNG-X will also require deployment to POLMI or POLSAP platforms. Where
this is the case a POLMI / POLSAP release will be scheduled for deployment immediately after
deployment of the DG Maintenance Release to live.
Once the POLSAP process has been updated a POLSAP update schedule will be agreed and added to
the Release Management Maintenance Schedule. The following platforms and update timings need to
be taken into consideration for scheduling.
2.4.1 SAP Transports
The SAP landscape refers to the SAP development, test and production environments and how they
relate to each other. For POLSAP there are multiple SAP instances spread across the environments as
follows:
Development - PLD
Test - PLQ and PLE
Production - PLP
PLM (the Solution Manager system)
SAP Transports provide the mechanism for distributing updates within the SAP landscape. Transports
are used for configuration and program changes. Data changes are usually typed manually into each
system.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 18 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
2.5 Release Independent Releases
2.5.1 Reference Data Test releases
RDT is the Reference Data Team environment and is a deployment group in its own right. The RDT
environment is split into 4 sub environments:
RDDIV - Ref Data Initial Verification
RDDT - Ref Data Terminal Verification
RDDOV - Ref Data OSG (POL) Validation
RDDPL - Ref Data OSG (POL) Validation
Stand-alone platforms (e.g. single platform instances)
All applicable releases should be deployed to RDT prior to the live upgrade unless there is a valid
technical reason which prevents this.
2.5.2 Security patching
Security patching is release independent and is managed outside of the DG deployment routine and in
general security patches are not included in Maintenance or Major Releases. They are scheduled in the
Release Management Maintenance Schedule with a timeline of approximately 42 days (6 weeks), see
example below:
Deploye
Patch Released I PAB Integration/Test d
June Patches I 14-Jun-11 I 21-Jun-11 I 04-Jul-11 to 18-Jul-2011 I 26-Jul-11
There are 90 days to deploy non-emergency security patches but they are normally scheduled earlier to
allow for contingency.
Security patches are split into the following areas:
e PAB agreed patches
e Operating system kernel changes
e = Anti-virus engine
They are normally patches to the Red Hat (Linux), Windows and Solaris operating systems.
Red Hat Patches will include the DXC and other DGs.
POLSAP patching is currently outside this process and is the subject of a separate CP.
2.5.2.1. Patch Approval Board agreed patches
These are agreed by the Security Patch Approval Board and must be deployed to all Security Tier 1 and
PCI platforms within 30 days of the patch being released by the supplier. The remaining platforms and
non-urgent patches must be updated within 90 days. These timings are a customer requirement.
Patches are managed as a complete set for deployment to all platforms concurrently.
The definitive list of Security tier 1 and PCI platforms can be found in the PHIL.
2.5.2.2 Operating system Kernel changes
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 19 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Security Operations will raise a CP for any security changes that require Kernel changes, and hence
more testing, to be included in Major Releases.
2.5.2.3 Anti-Virus engine
Security Operations will raise a CP for any anti-virus engine changes that need to be scheduled.
2.5.3 Operational changes
There are occasions where an urgent change is needed to the live estate to ensure the continued
running of the business. These are documented and tracked in MSC and will, where possible, be applied
and tested on LST before application to live.
Following application to live, a call is raised which normally results in a Peak. This is passed to
Development for review and is then processed in the normal way through the BIF /PTF and included in a
future Maintenance or Major Release.
2.5.4 Platform builds / rebuilds
For Data Centre and platform upgrades, builds or rebuilds:
RM raises a single Admin Peak where no CP or Peak exists to document the requirement
Anew Maintenance Release number for each build is allocated during the Release Planning meeting
APM or work package manager is selected and assigned by a representative at the Release Planning
meeting. This is part of the release planning process and the appointed person is emailed directly
In order for the release plan to commence, a detailed list that contains all new platforms with their
associated DGs should be held in PHIL. The PHIL updates will also facilitate the correct Peak updates
which are required in order to ensure the platform is upgraded with the correct security patches or DG
releases
Fixes of this type can be released in parallel with other Maintenance and Major Releases.
2.5.5 Common Products
Acommon product is a baseline that is to be applied across all platforms within an operating system type
(e.g. Windows) and is contained within the common product stack (this can be viewed within Dimensions
via workset SCM_PLATFORM_ATTRIBUTES_NA, selecting ScmPlatformStack_WIN etc). It is not to
be confused with a baseline that is applicable to more than one platform type.
Common product does not apply to a baseline that is applicable to more than one platform type. A
common baseline release is tested within the DG release that targets the fault Peak. Once the common
product has been signed off as fit for live, a further release note is raised regarding its application to the
remaining platforms within LST and tested as a background activity. After sign off, the common product
is scheduled for live application.
2.5.6 Backlog
Backlog contains arrears of baselines that are in line for testing and / or application to an environment
e.g. a common product can be considered backlog once deployment has begun.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 20 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
3 Release Planning
3.1 Release Planning
Purpose To oversee the release process and associated activities to ensure the smooth
running of the process and successful delivery of releases.
Release Planning meets to address the following topics:
Status
Review of actions.
Review of Release Schedule / Customer Forward Schedule of Change
Update on Programme activities
Update on Service Projects
Update on Service Improvement Activities
Escalation
Issues raised from BIF / PTF
Quality issues with the process
Escalations required (POL, third parties)
Participants Head of Release Management, Application Manager, Test Manager, Release
Programme Managers, Release Team Manager, Maintenance Release
Manager, Problem and Incident Manager, Integration Manager, SSC Manager
Invitees SDMs with projects, BCP, Project Managers
Duration 1 hour
Frequency Twice Weekly
Mandatory Input Release Schedule (Internal), Forward Schedule of Change
Mandatory Output Minutes recording proceedings, actions and agreements.
The meeting objectives are to review and agree:
¢ The overall schedule of Releases
e Changes to the existing Release Schedule
e Inclusion of CPs into maintenance slots when the CP is at the agreement to raise,
impact, and approved stages
* To remove Cps from maintenance slots when the CP is at the removal stage
e The resolution of any issues arising from BIF / PTF and related to the Release Schedule
¢ Addition of new Maintenance Releases
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 21 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
e The frequency with which each DG is scheduled. This should be done before the
deployment of a Major Release to LST. This enables the forward schedule of DG
Maintenance Releases between the next two Major Releases to be adjusted if needed
3.1.1 RP Objectives — 6 Week Release Plan (Tuesday meetings)
Agenda: Review forthcoming releases
Confirm Development and Integration deliveries are on target
Confirm Peaks are targeted at the correct release for the DG that will take the fix
Confirm Peaks are progressing through the process as expected
Confirm the dates for Maintenance Releases are being updated in Peak as per Appendix 5
Highlight anomalies to the attendees for resolution
Confirm that releases are on target to hit their test and deployment dates
Confirm/Identify deliveries
3.1.2 RP Objectives - Upcoming Release Plan (Thursday meetings)
Agenda: Review Release Plan
Discuss forthcoming CPs
Review changes to dates of Maintenance Releases
Add new Maintenance Releases
Review frequency with which each DG is scheduled
3.1.3 RP Attendees
Origination Role
RM - Release Controller Chair
RM — Release Planner Minutes
Application Development Contributor
Service Management Contributor
Release Management Contributor
Infrastructure Development Contributor
Test Contributor
SSC Contributor
Integration Contributor
Programme / Project Management Contributor
3.1.4 RP Inputs
Source Details
Release RM The release planning meeting uses a spreadsheet to inform the meeting.
Schedule The spreadsheet uses data, including release planning records from
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIALIN _ Ref. SVMI/SDM/PROI1520
CONFIDENCE) Version 1.0
Uncontrolled if Printed or Distributed Date 26/01/2015
Page No: 22 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Peak to manage, control and review the release contents. The concepts
behind the release planning records on Peak, and their use, are
documented in ‘Peak Release Planning Facilities’. The data from Peak is
exported into the Release Schedule which is stored on SharePoint.
Forward RM The Forward Schedule of Change is stored on SharePoint and updated
Schedule of weekly to reflect changes agreed in Release Planning.
Change
PTF Minutes I RM The PTE Minutes are issued weekly on Mondays detailing any new
maintenance slots required.
3.1.5 Outputs
Output Source Details
Release RM A new version of the Release Planning Minutes are kept on SharePoint
Planning and updated after every meeting to show the actions agreed in Release
Minutes Planning.
Release RM The Release Schedule is kept on SharePoint and updated weekly to
Plan show changes agreed in Release Planning.
3.2 Business Impact Forum (BIF) & PEAK Targeting Forum
(PTF)
This meeting is held once a week on Monday.
An emergency PTF is held for any Peaks which are sufficiently urgent that they need to be targeted
before the next scheduled meeting.
For information on BIF and PTF refer to document SVM/SDM/STD/2593 (Terms of Reference for POA
BIF and PTF).
3.3 Quality Filtering Process (QFP)
For information on QFP refer to document DE/PRO/015 (POA Systems Integration Directorate Incident /
Defect Management)
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 23 of 43.
Fe)
FUJITSU
Release Management Strategy
CONFIDENCE)
FUJITSU RESTRICTED (COMMERCIAL IN
FUJ00232666
FUJ00232666
4 Plans
There are a number of plans which drive the End to End Release process.
Plan Feeds from Feeds
Programme I Overall programme/account plan Release Plan
Plan
Major PM/Major Release Manager plan Release Plan
Release
Plan
Release Programme Plan RM Breakout Plan
Plan
BC Plans
Major Release Plan
Test Plans
Integration Plans
Datacentre Plans
POL changes
Development Plans
Operations Security Plans
spreadsheet
Test results
PCI audit Operations Business Continuity
Pen Testing Deployment teams
CPs Forward Schedule of Change for POL
PAB dates High Level Deployment Plans
High Level Deployment Plans
RM Breakout I Release Plan
plan
Release Release Plan Test and deployment activities
pabloyment ‘Platform upgrades and outages’
4.1 Maintenance Release Schedule
The Maintenance Release Schedule is stored on SharePoint and updated by the Release Planner after
any changes made in the Tuesday / Thursday Release Planning meetings.
Representatives from each department at the meeting can voice opinions and concerns, the updated
Release Schedule is then uploaded to SharePoint and the link distributed by email every Friday.
Dates to be changed in the RS are agreed with the Integration, Test and Development representatives in
the meeting.
To ensure there are no conflicts of interest relating to usage of the environments the RS includes details
of the following:
DG Maintenance Releases
Security patching drops
Multi-DG Releases
Business continuity testing dates
© Copyright Fujitsu Services Ltd 2015
Uncontrolled if Printed or Distributed
FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Date: 26/01/2015
Page No: 24 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Data Centre outages
Major Release deployment dates on LST and live
POL changes
PCI audits
Datacentre power outages
Release independent CP work
For Maintenance Releases the plan contains the following:
Date when Peaks will no longer be targeted
Date by which Development need to deliver
Date by which Integration need to process the baselines
Date by which RM will provide a RN and PSPID to LST
Dates during which LST will test the release
Date by which RM will provide a RN and PSPID for live deployment
Date or time period for live deployment
Date for RDT deployment
When discussing the possible Maintenance Releases that can be accommodated between two Major
Releases the content and concurrency is agreed with the Test representative before a fully detailed plan
is distributed further for comment.
This plan is used by POA as the definitive source of information regarding Maintenance Releases. It is
supported by plans from other units which detail the work they need to undertake to achieve the
committed dates in the Release Schedule.
Changes to the Release Schedule are proposed and agreed in the Release Planning meeting. Any
escalations / contentions will be highlighted to POA Operations Management and POA Programme
Management for discussion and agreement.
4.2 Forward Schedule of Change (FSC) for Atos / POL
Atos / POL require a forward view showing a 6-month rolling schedule of change. This plan shows dates
when the online service will be unavailable. They also require a view showing the detail of the changes
planned in the next four week period.
Inputs to the FSC are taken from the Release Schedule, the MSC system and the POA Service Delivery
Managers. The FSC is circulated internally and sent to Atos weekly on Fridays.
This FSC is produced by the Release Planner.
4.3 Release Deployment plans
Release deployment plans are needed at two levels, the detail for specific releases and at a high level
for general planning with Atos / POL and the raising of MSCs etc. Both plans must take into account the
Sunday Trading discussions which mandate that, except in special circumstances, the counter must be
available for trading from 10am to 5pm on Sundays.
Each deployment plan will be discussed with LST and UNIX/NT for both LST and Live.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 25 0f 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
4.3.1 High level deployment plans
On the provision of a new version of the Release Schedule a high level deployment plan is required to
finalise the deployment dates for live. The dates for deployment to live are then fed back into the
Release Schedule and are used in the production of the Forward Schedule of Change for Atos / POL.
To construct the updates to the Release Schedule each release will be reviewed to determine the
probable day / time the change will be deployed to live. This is done using the spreadsheet Platform
Deployment Crib Sheet.
This will be done by the Maintenance Release Manager who will feed dates back into the Release
Schedule via the RM Planner.
Major release plan dates are also fed back into the Release Schedule via the Major Release Give / Gets
plan. Forums are set up and run by the PM assigned to the Major Release.
4.3.2 Detailed deployment plans
Detailed release deployment plans are produced for Major and Maintenance Releases. They are
produced by the RM team and are agreed with the Deployment and relevant Test teams.
The plans are attached to the relevant RNs on Peak and to the MSC which is being used to monitor the
deployment. They will include at least the following detail:
Deployment ordering
Timings
Special instructions
The split of deployment where manual baselines are being delivered
Detail if any reboots will be performed by the upgrade
ec eee
Rm are also responsible for maintaining a portfolio of the Release Deployment Plans, so they can be re-
used for future releases or release cycles. There is a library of Release Deployment Plans and
templates in the service introduction area of \\EuropeMUK097.
4.3.1.1 Detailed live deployment plans
At times a number of DGs, although tested individually in LST, may be combined and deployed as part
of a joint activity. The individual deployment plans for each DG are concatenated into a single detailed
deployment plan for use on the live estate.
The producer of the deployment plan for live must check and include where appropriate all comments
made about the release by the Test team. This is to ensure that any deployment issues are not lost when
the release is deployed to live.
4.4 Deployment Plan Walkthrough
A deployment plan walkthrough WI is available through the document reference SVM/SDM/WKI/2689
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 26 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
5 Release contents
The list of baselines in a release is available in Dimensions, represented by an Excel table and shared
by LST and Integration for information. The release content determines not only which baseline is
included but also involves using the result of performance measurement to calculate risk and share
knowledge in the RM team.
For details of which baselines are included in a release and how this is validated to ensure the integrity
of the live environment see Appendix 7.
5.1 Major Release contents
The majority of the content of a Major Release is derived from internal and external CPs. Some Peaks
which are inappropriate for a maintenance slot are allocated to a Major Release via the BIF / PTF
process. Any peaks targeted at a Major Release by the BIF / PTF must be agreed by Test and the
Project Manager managing the release.
5.2 Maintenance Release contents
The Release Schedule indicates, for a point in time, whether a Maintenance Release has any content.
This information can also be obtained from a search on Peak.
The content of a specific Maintenance Release for a DG is made up of a combination of the following:
e Peaks - which are targeted at a Maintenance Release via the BIF / PTF process
« Approved CPs which are for deployment outside of a Major Release — once the DGs affected by
the CP are known a Peak is raised to track the delivery and deployment of the CP within the
appropriate Maintenance Release. The inclusion of a CP is agreed by Release Planning
e Baseline catchup — identified by Integration and includes common products which have not
previously been applied to a specific DG. If the backlog includes deliveries for a CP then this CP
and the totality of what it delivered must be reviewed to ensure the inclusion is valid
Test regularly review the contents of Maintenance Releases and have the responsibility to inform the
Release Planning meeting when a release is full and no more Peaks can be included. At this point RM
update the description of the release on Peak to that effect.
5.2.1 Change Proposal inclusion
For information on the CP Process refer to the latest version of document PGM/CHM/MAN/0002
(Change Management Instructions).
Once a CP has been raised and approved RM follow the process below.
ACP goes through a number of stages, the first of which is ‘Agreement to Raise’. At this stage the CP is
checked to ascertain whether it is intended to deliver any baselines to live and whether it is intended for
a Major Release.
CPs targeted at a Major Release will be managed by the POA Major Release Manager and can be
ignored for the purposes of this section of the document.
CPs targeted at anything other than a Major Release and intending to make a delivery to live must be
discussed and tentatively included in the Release Schedule. Once the CP is approved it will be
confirmed for inclusion in a Maintenance Release. It is the responsibility of Release Management to
ensure that CPs are discussed and included or removed as required. These discussions take place at the
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 27 0f 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Release Planning meetings. The delivery team need to reference these peaks in their baseline delivery
to Dimensions. Admin Peaks are not required for Major Releases that go through SV&l.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 28 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
6 Release tooling
In the context of this document for the creation and deployment of any release the units involved use a
number of tools to drive the process.
Plan Feeds from Feeds int
Dimensions Development Contents Log
Peak Dimensions Release Planning Spreadsheet
Contents Log
Dimensions
Release Schedule Development RM Release Spreadsheet
LST
Live
TPM PSPID Contents Log
Contents Log Peak RM Release Spreadsheet
Dimensions PSPID
TPM
Release Checking Database
Integration
Test
Development
PSPID Build Document SSB
BOM
RN
Build Document Dimensions Release Deployment Plan
Contents Log MSC
PSPID
SSB Build Document Release Deployment Plan
RN Contents Log Authorisation for Release
PSPID MSC.
Build Document
MSC Contents Log Authorisation for Release
PSPID
Build Document
Release Deployment I RM Release Spreadsheet Deployment
Plan Implementation Team
Build Document
SSB/BOM
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIALIN _ Ref. SVMI/SDM/PROI1520
CONFIDENCE) Version 1.0
Uncontrolled if Printed or Distributed Date 26/01/2015
Page No: 29 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
6.1 Dimensions
Dimensions store all the baseline deliveries made by Development and the deployable baselines created
by Integration. These deliveries contain handover notes which are read by Integration and any
information which may be needed during Deployment. These are added into the Dimensions attribute
‘RM Special Instructions’. These special instructions may include details such as if several groups need
to be involved in the deployment.
Dimensions provides an extract for inclusion in the Release Checking Database.
6.2 Peak
Peak is a web based application used for storing Peaks, which include information such as;
¢ RN Number
«Target Release
«Target Platforms
* Baseline
Peak provides a list of the Peaks which should be included in the release. This can be stand alone or via
the Release Planning spreadsheet.
Peak also provides a number of reports which are used for the Release Planning Spreadsheet.
Peak also provides an extract from Dimensions for inclusion in the Release Checking Database.
6.3 Release Schedule
The Release Planning Spreadsheet is used to check that all Peaks expected to be included in the
release are picked up. A release can include Peaks which were targeted and delivered at a previous
release but are to be delivered with a later release. These Peaks need to be tested so are picked up via
the release planning spreadsheet. It is also used to check that all Peaks are targeted at the correct DG
Maintenance Release.
This spreadsheet is generated by the RM Planner and is updated at least twice a week.
6.3.1 Baselines
All releases are made up of a set of baselines, which will be classified in Dimensions as either Auto or
Manual. Baselines are created in Dimensions and linked to a peak and or a CP. The Peak system
regularly updates individual Peaks to add in any linked baseline names. The baseline name includes
sufficient details that the target release can be presumed
6.4 TPM
TPM is the tool used to make auto deployment of baselines to the estate. In rare circumstances a
baseline may be withdrawn and regressed from a platform. If a regression is performed a special script
must be run on TPM to ensure that it no longer thinks the baseline is deployed.
6.5 Content Log
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 30 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
During a release timeline a number of reports are required relating to which baselines will actually be
deployed. These reports are used by RM to ensure the contents of the release are understood, agreed
and thoroughly cross-checked.
The complete detail of how these reports are used is included in the RM processes and the E2E release
process flowchart. Content Log — Work Instruction
6.6 RM Release Spreadsheet
The RM Release spreadsheet is produced and used by the RM Release Controller to document and
agree the release. It contains a number of worksheets which are used in the various stages of the
release. An individual spreadsheet refers to the deployment on a specific rig so for a single release there
may be two spreadsheets, one for LST and one for live. The way the spreadsheet is used is documented
within one of the worksheets.
It also includes the deployment plan for the release.
An excel template spreadsheet is held on SharePoint RM Working Templates, they are updated on a
Half yearly basis.
6.7 Build document
The build document is provided by Integration. It is used by SCM to produce the PSPID and SSB. The
contents of the build document is produced using, at least in part, the RM Release spreadsheet.
6.8 PSPID
APSPID is provided by SCM in line with the build document. This provides all the software and meta-
data to the deployment team for the potential deployment to a rig.
6.9 SSB
An SSB is also provided with the PSPID by SCM. The SSB is used by RM to check that what will be
deployed by the PSPID is what was expected and agreed.
This spreadsheet is input to the Release Checking Database.
6.10 MSC
MSC is the change management tool used to gain POA and Atos approval for the deployment of
change. It is also used to direct the deployment teams on the detail of the activity and retains an audit
trail of the approval and deployment of the change. With the exception of Ref Data Deliveries.
An MSC is raised for every deployment to live and LST and includes a copy of the RM Release
Spreadsheet.
Atos requires seven working days’ notice of any deployment to live.
6.11 Release Notes
For each release Test expect to receive a single RN for the release. During the course of testing
additional RNs may be provided to deliver additional fixes to the original release.
For each Maintenance Release to live the deployment team expect to receive a single RN for the
release. Any additional fixes supplied to test will be included in the PSPID for live so only a single RN
should be necessary.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 31 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
For each release RM creates an additional RN is created for each platform to which a Manual baseline is
to be deployed. This RN is for administration purposes only to ensure that it is understood in Dimension’s
that the baselines have been included on a RN. The RN does not go to the Test or Deployment teams.
Each RN exists as a Release Peak on Peak. The Release Peak contains a reference to the MSC and
includes a copy of the RM Release Spreadsheet.
RNs which carry just TAGS files will reference only a single Administration Peak.
6.12 Release Deployment Plan
The Release Deployment Plan is a full level 4 plan, the plan consists of information from RM Release
Management Spreadsheet, Implementation Teams, Build Document, SSB, BOM and Release Notes.
The plan is then used by Release Management team to ensure full delivery of the release. The plan
contains:
e Deployment Timings
e Deployment Dates
e Implementation Teams
6.13 Bill of Materials (BOM)
ABONM is also provided with the PSPID by SCM. The BOM is used by RM to understand the phases
used and manual baselines to be deployed.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 32 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
7 Monitoring of the End to End Methodology
7.1 Key Performance Indicators
Key performance indicators will be maintained for various areas related to the E2E release process. This
will be done manually until a full set of requirements is available and automation can be defined / agreed
and implemented.
The release planning records in Peak have the ability to track the planned and actual dates for a number
of activities. The Release Plan could provide details as to whether a release met the dates if Baselines
were used.
Ref Data deliveries do not fall within the scope of Release Management
7.1.1 Major Release Key Performance Indicators
Deliveries out of development on time
Deliveries out of Integration on time
Release available to LST for deployment on time
Release out of LST on time.
Release ready for deployment to live on time
Release deployed to live on time
7.1.2 Maintenance Release Key Performance Indicators
e Maintenance Release KPIs are manually recorded on the Release Planning spreadsheet. The
current measures for each release are:
Deliveries out of development on time
Deliveries out of Integration on time
Release available to LST for deployment on time
Release out of LST on time
Release ready for deployment to live on time
Release deployed to live on time
7.1.3 Security patching Key Performance Indicators
« Deliveries from vendors on time
« Deliveries out of Integration on time
e Release available to LST for deployment on time
e Release out of LST on time
e Release ready for deployment to live on time
e Release deployed to live on time
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIALIN _ Ref. SVMI/SDM/PROI1520
CONFIDENCE) Version 1.0
Uncontrolled if Printed or Distributed Date 26/01/2015
Page No: 33 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
8 Roles and responsibilities
8.1 Release Management
8.1.1 Head of Release Management
The Head of Release Management is responsible for the overall delivery of the RM service, and owns
the Release Policy and Release Management Strategy.
8.1.2 Release Management Team Manager
The RM Team Manager is responsible for ensuring that CPs are included and handled correctly within
the process, and owns the E2E Release process and the line management of the Release Controllers
and Release Managers.
This model allows for both the Release Management Team Manager & Major / Maintenance Release
Managers to manage the Release Controllers on a day-to-day basis. The work allocation is managed by
the Major / Maintenance Managers based on the direction given by the Release Management Team
Manager to the individual Release Managers/Release Controllers.
8.1.3 Major Release Manager
The Major Release Manager is a member of the RM team and is responsible for the production and
management of the deployment of Major Releases to SV&l, LST, RDT, and live, which includes creating
plans for Major Releases.
The Major Release manager is also responsible for the following:
e The quality of data exiting RM relating to Major Releases
e Input into the Forward Schedule of Change for Atos / POL from the Major Release Schedule
e Joint monitoring of the delivery of product version baselines (PVB) by development into Integration
and the subsequent consideration for inclusion of Deployable Product version baselines (DPVB) into
the Major Release
e Joint identification with Integration of which Peaks / CPs have not been delivered in the correct
timescales. Note: RM are not responsible for identifying that all design parts have been delivered as
this is a handshake between Development and Integration.
e Escalation of identified missing deliverables to the responsible Programme Manager to assess
impact and agree potential deferral with the customer
e Ensuring that Peaks which have not been delivered are given a target release of ‘Target missed
need to re-target’ and Development are aware so they can route to PTF for a new target
e Ensuring that nothing is going live which has not been on LST — unless agreed prior to release.
« Co-ordination of RDT updates (done by both the Maintenance and Major Release managers)
e Ensuring that the SSB content has been checked against expected content, plans and LST
deployment
8.1.4 Maintenance Release Manager
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 34 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
The Maintenance Release Manager is responsible for the production and management of the
deployment of Maintenance Releases to SV&I, LST and live, which includes creating plans for
Maintenance Releases.
The Maintenance Release manager is also responsible for the following:
e Maintaining Contents Logs
e The quality of data exiting RM relating to Maintenance Releases
e Joint monitoring of the delivery of product version baselines (PVB) by Development into Integration
and the subsequent consideration for inclusion of Deployable Product version baselines (DPVB) into
the Maintenance Release
e Joint identification with Integration of which Peaks / CPs (in Contents Log) have not been delivered
in the correct timescales. Note: RM are not responsible for identifying that all design parts have been
delivered as this is a handshake between Development and Integration
e Escalation of identified missing deliverables (if all deliverables are supplied by the PM) to the
Operations Manager or SDU Stakeholder to assess impact and agree potential deferral with the
customer
e Ensuring that all releases going to live have LST sign off- unless agreed prior to release
e Ensuring that the SSB content has been checked against expected content, plans and LST
deployment (where the release is for Live)
e Co-ordinating RDT updates (done by both the Maintenance and Major Release Managers).
8.1.5 Release Planner
The Planner is responsible for the following:
« The maintenance of the Maintenance Release plan
e The production and updating of the RM Breakout plan
e Production of the RM Release spreadsheet
e The Release Management planning spreadsheet
e Maintenance of planning records on Peak
« Escalating potential issues with the plans
« Maintenance of the Release details on Peak should they change during the planning process
e Maintaining and distributing the Forward Schedule of Change
8.1.6 Release Controller
The Release Controllers is responsible for:
e Updating Release description on Peak when a Maintenance Release reaches the cut-off date
e Raising of MSCs for the release
e Chairing Release Planning Meetings
e Ensuring Peaks which have not been delivered are given a target release of ‘Target missed need to
re-target’ and development are aware so they can route to PTF for a new target
« Production and closedown of RNs
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 35 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Managing any Peaks raised by the Test unit to ensure that Development can deliver on time and
that appropriate RNs are then raised and passed to test
Act as a single point of contact for any issues arising from the testing or deployment of the release
Maintenance of planning records on Peak
Use release checking database
Working with the dates in the RM Breakout Plan
Adding a Final Response to all Peaks which have successfully passed test and ensure they are
routed back to originator for closure
Create Administration peaks for TAGS RN's and target at Release Independent
Create Administration peaks for CP's
Validation of the SSB for a release against expected content and LST deployment (where the
release is for live)
8.1.7 Peak Targeting Forum Administrator
The PTF is responsible for:
Targeting peaks at releases
Creating Maintenance Releases on Peak
This is done once the PTF have agreed that a Peak should be targeted at the release. The
information required for creation of a release should come from the Maintenance Release plan.
Release Management create the release on Peak and Dimensions, then supply the information to
SCM and Integration respectively.
Maintenance of planning records on Peak
8.2 Development
Development is responsible for:
Escalating to the Release Planning Meeting if a Peak or CP will impact additional platforms to those
defined when the Peak / CP was targeted at a release
Only developing a change once the Peak / CP has been targeted
Asking Integration to withdraw baselines which must never be deployed
Ensuring that peaks are passed on to RMF promptly where release targeting is approved
Participating in RMF meetings to provide apps development input to release priority
Participating in release planning to provide apps development support of release planning decisions
and setting of release dates
Ensuring code fixes are delivered to the relevant release delivery toolsets in accordance with the
agreed release plan.
Ensuring each Peak status is maintained consistent with development and release processes.
8.3. Integration
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 36 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Integration is responsible for:
Processing all deliveries made by Development
Providing confirmation to RM on the contents of a build via the RM Release Spreadsheet
Production of the Build Document
Ensuring that all baselines which will initiate a reboot are documented as such in the Special
Instructions in Dimensions
Ensuring that any special instructions in the handover from Development are included in the Special
Instructions in Dimensions
8.4 SCM
SCM are responsible for:
Production of the PSPID
Production of the SSB
Delivery of software and associated meta-data to the DXT
Delivery of the release to the DXT
8.5 Test
Test is responsible for testing:
Emergency hot fixes, Peak fixes delivered in Maintenance Releases, internal service improvements
via approved CPs, and POL requested business functionality changes via approved CPs
Reviewing and agreeing the Release Schedule and the Release Planning Spreadsheet in the
Release Planning Meeting
Production of Test Plans
Signing off or rejecting the release
Assisting PEAKs at BIF and PTF
Reviewing document plans for LST, RDT and Live
Recording Test results
8.6 Architect
The Architects are responsible for:
« Updating the PHIL for new platforms prior to them being released from Development and
signed off before they are planned to go into Integration.
«Producing a Migration Strategy that feeds into the RM Deployment Plan. This should be
reviewed internally and externally
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 37 of 43.
Fe)
FUJITSU
Release Management Strategy
CONFIDENCE)
FUJITSU RESTRICTED (COMMERCIAL IN
FUJ00232666
FUJ00232666
9 Appendices
9.1 Appendix 1 —- Deployment Groups
This Appendix details the current frequency recommendations around the scheduling of DGs into
Maintenance Release slots. Note that these may not be required at these frequencies for a variety of
reasons, e.g. the number of Peak fixes in existence that need the specific DG Maintenance release, or
customer requests for new functionality releases which take priority over DG Maintenance releases and
may include Peak fixes in order to be able to deliver the functional release.
DG Frequency
DG_ACCESS Every 3 months
DG_AUDIT Every 2 months
DG_BACKUP Every 6 months
DG_BAL Every 6 weeks
DG_BANKING Monthly
DG_DATABASE Every 3 weeks, every other one with the counter
DG_Decom na
DG_EMC Every 6 months
DG_Estatemgt Monthly
DG_FTMS Every 2 months
DG_HORIZON Every 6 months
DG_individual ‘As and when needed but at least once a year
DG_INITIAL Every 3 months
DG_KEYS Every 6 months
DG_NETWORK Every 6 months
DG_POLMI need to discuss
DG_POLSAP, need to discuss
DG_RDT Following on from other DG releases
DG_SECURITY Every 6 months
DG_SUPPORT Every 6 months
DG_Sysman2 Monthly
DG_SYSMANS Monthly
DG_VIRTUAL As and when needed but at least once a year
Every 3 months
DG_WEB
There must be a slot in April and November
DG_noinstance wa
Counter infrastructure need to discuss
Counter App Every 6 weeks
TWS schedule Every 8 weeks
Usual timescale for testing is 10 working days.
9.2 Appendix 2 — Cloned Peaks
© Copyright Fujitsu Services Ltd 2015
FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Uncontrolled if Printed or Distributed
Ref
Version:
Date:
Page No:
‘SVM/SDM/PRO/1520
1.0
26/01/2015
38 of 43
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Clone peaks must be created by either Test or the SSC. As Test peaks generated from QC cannot be
cloned a new QC defect will be created.
9.3 Appendix 3 — Release numbering
9.3.1 Major Release
Additional release numbers are used for a Major Release to control the various drops of software that are
delivered. These are of the format xx.nn.mm.yy where:
xx is the Major Release number
nn is usually 00 but is set to 01 for deliveries that will go direct to LST for testing
mm is a number which starts at 00 and increases by 1 for each cycle of testing
yy is a number which is used to represent the rig for a PSPID release. It is used as follows:
00 to 09 is ITU1 (SVI)
10 to 19 is ITU (was Vol)
20 to 29 is POLSAP
30 to 39 is LST
40 to 49 is RDT
50 to 59 is Production (live).
9.3.2 Maintenance Release
Each Maintenance Release slot will be given a release number in the format xx.nn where:
xx relates to the last Major Release
nn is just a number with no sequence implications, taking values between 10 and 99.
There is one caveat to the ‘no sequence implication’ and that is that for every given DG type) e.g.
DATABASE) the release number must be in numerical order so 03.16 must be deployed before 03.20
before 03.21
Although some of the tooling can use additional quartets in a release number these are NOT used for the
actual release process.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 39 of 43
FUJ00232666
FUJ00232666
(oe) Release Management Strategy
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
9.4 Appendix 4 - Release planning facilities / dates in Peak
Peak has a set of facilities which are used for release planning. These need to be maintained as follows:
Field Associated with: Initial set up Maintained by:
Plan out Dev I Fault Peak Set to the value associated I This value can be set by Development if they
with the Release in Peak expect to deliver past the expected date
Release Peak when a Peak is targeted
If the Release dates change RM will reset the
Target Release date from the Target Release screen on Peak
Plan out Fault Peak Seto the value associated I This value can be set by Integration I they
Integration with the Release in Peak expect to deliver past the expected date
Release Peak when a Peak is targeted
If the Release dates change RM will reset the
Target Release date from the Target Release screen on Peak
Plan into Test I Target Release
Plan out Test I Fault Peak Set to the value associated I This value can be set by Test if they expect fo
with the Release in Peak deliver past the expected date
Release Peak when a Peak is targeted
If the Release dates change RM will reset the
Target Release date from the Target Release screen on Peak
Plan into Live I Fault Peak Set to the value associated This value can be set by RM if they expect to
with the Release in Peak deliver past the expected date
Release Peak when a Peak is targeted
If the Release dates change RM will reset the
Target Release date from the Target Release screen on Peak
Release Target Release RM update this when a release is full and no
description more peaks should be targeted
RM update this when the release has reached
it's cut-off date
RM update to add in the name of the Release
Controller for the release when it is known
Collection Target Release The collection associated
with the release is added to
the Peak when itis targeted
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 40 of 43.
FUJ00232666
FUJ00232666
Release Management Strategy
Fe)
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
9.5 Appendix 5 — Baseline inclusion in a release
As part of the RM process for a release RM review the baseline backlog which are possible targets for
the release. The contents of the release are then agreed with Test, Integration and Development (where
necessary).
Each baseline is afforded a status within the release as follows:
Exclude — baseline NOT to be included in the build document or PSPID & SSB
Include — baseline to be included in the build document, PSPID & SSB and will be deployed by the
release
Applied — baseline to be included in the build document, PSPID & SSB but will not be deployed by the
release
Once the SSB and PSPID have been produced RM check the contents of the SSB to ensure that it
includes the expected baselines. RM also checks that what is expected to be deployed to live has
already been deployed to LST. These checks ensure the integrity of the build and hence what will be
applied to the live environment.
It is important to note that checks MUST be done at a platform type level as any baseline which is
included in the PSPID & SSB will apply to ALL platforms types which are being upgraded by the release.
9.6 Appendix 6 — Fault Peak Lifecycle
This section outlines the lifecycle of fault Peaks and the responsibility at each level.
The basic Peak Lifecycle is as follows:
e Open Initial state of a Peak call
e Pending Incident is being investigated
e Final Investigations have finished Final response is sent back for approval
e Closed Final state - call is closed on the Peak system.
If a Peak has been sent to a team it is that team’s responsibility to monitor it, send it on for investigation,
fix it or release it to the correct Peak stack
Example: A Peak is raised by Integration with the comment “Build Description not correct or doesn’t
work”. The Peak should identify where the build fault is if known, or alternatively provide some
supplementary information to enable investigation.
Responsibility is initially with Integration to send the Peak to the “Build Owners / Development” stack for
investigation.
Accountability is always with the team leader / manager on whose stack the Peak resides. So for a Peak
which is on an incorrect stack, or if it needs attention by another team, it is the Peak stack manager’s
responsibility to reroute it as soon as possible, consulting the team to whom it is being sent by email /
phone / text if it is urgent.
The Peak is then investigated by Development and if a fix is required it should be sent by them to the
BIF stack for consideration of the business impact.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 41 of 43
FUJ00232666
FUJ00232666
oO Release Management Strategy
FUJITSU FUJITSU RESTRICTED (COMMERCIAL IN
CONFIDENCE)
Responsibility is with Development / Design to send the Peak to the BIF before fixing, and to provide an
impact statement on the Peak of how long it will take to fix and what it would impact taking into account
other development activities, including any issues with the order of the code update or release.
If the BIF decide that a fix is not warranted for cost or other reasons, the Peak detail is added to the
Known Error Log (KEL), the Peak is closed, and the originator is informed.
If the BIF decide that the Peak should be fixed it is returned to Development for further comment, and is
then sent on by them to the PTF stack for targeting. They should also inform the originator that it is
being sent for targeting and inform the RM team by email / phone / text if it is urgent.
The PTF will assign the Peak to a target release if one exists. If a suitable target release does not exist
the Peak is referred to Release Planning for a Maintenance Release to be created.
Responsibility is with the PTF to get the Peak assigned to a target release and associated timeline.
Accountability also lies with the PTF to ensure it has an appropriate target.
The developers, Integration and Release Planning should be consulted when targeting the Peak to
ensure that the timing would work, taking into account other development activities, including any issues
with the order of the code update or release.
The Peak is then sent back to Development to deliver the fix.
Responsibility is then with Development to deliver the Peak and route it to Integration.
Accountability for confirming the fix is then with Integration, who should consult with Development, Test
and Release Management to confirm how the build is progressing, a day or two before the out of
integration date.
Integration then inform Development, Test, and Release Management whether the build was successful.
Sign Off: Integration close the Peak. If the Peak was not fixed it would have been communicated at the
inform stage.
Note: Peak will enforce this call lifecycle so it will not allow a Final response to be entered unless the
current status is “Pending”, and a call cannot be closed until its status is Final.
For detailed Peak information please see the Peak website's “help” or the document CSMANO11 - Peak
User Guide.
‘© Copyright Fujitsu Services Ltd 2015 FUJITSU RESTRICTED (COMMERCIAL IN Ref: ‘SVM/SDM/PRO/1520
CONFIDENCE) Version: 1.0
Uncontrolled if Printed or Distributed Date: 26/01/2015
Page No: 42 of 43