This is a controlled document. Prior to using this document, IT MUST BE CHECKED against the current revision held in the DAL
Fife Council - IT Services
Release Management Strategy Version: 1.0.0
Version History Summary
Issue Description Date 0.0.a Initial Draft. 01/03/10 0.0.b Second Draft. 16/03/10 1.0.0 First release following DRN 15/04/10
Author: Lesley Wardrope Date: 16th March 2010
Version: 1.0.0 Page 1 of 5 Release Management Strategy This is a controlled document. Prior to using this document, IT MUST BE CHECKED against the current revision held in the DAL
1. INTRODUCTION
This document is designed to provide Release Management definition, objectives and scope as well as providing the approach to Release Management. Extra vigilance needs to be placed around Release Management in order to avoid service disruption directly attributable to Release activity and to ensure that we deliver service stability.
2. DEFINITION
A Release is any fix, update or incremental code release intended to enhance functionality, resolve security, reliability or other serious operational issues.
3. OBJECTIVE The objective of Release Management is to ensure that releases are deployed in a timely fashion with the minimum of business disruption.
4. SCOPE
Area Description Network & voice devices Initially all switches and routers, voice gateways and Voice Core components (as defined in support contracts) Electronic Gateway firewalls, mailsweepers and other key devices
Server operating Windows, Unix, Solaris, Linux and Netware Systems Server and storage Firmware and BIOS for servers firmware Critical IT Support tools CA Systems Management, Assyst and Commvault Critical Business as defined by Corporate BCM Applications Desktop Operating Windows, Internet Explorer and Firefox Systems and web- browsers End-point security anti-virus, spyware and encryption technologies Standard Applications Standard desktop applications (MS Office, Adobe Acrobat etc)
Version: 1.0.0 Page 2 of 5 Release Management Strategy This is a controlled document. Prior to using this document, IT MUST BE CHECKED against the current revision held in the DAL
5. STRATEGIC APPROACH
There are 4 overarching strategic approaches.
Name Characteristics Relevance This approach is characterised by This approach is Quarterly bundled together in scope releases suitable for Release for a pre-agreed release window applications that once per quarter. have a high level of candidate releases. This approach is characterised by This approach is Checkpoint performing assessments at pre- suitable for Assessm defined points throughout the year applications that ent to ascertain if any of the candidate have lower levels of releases are to be deployed. candidate releases. This approach is characterised by This approach is Ad hoc being a more reactive incident suitable for Approach driven approach. A request for a applications that are release must be made by a externally managed supplier / customer / IT support. or are on very stable environments. This approach is characterised by This approach is Automatic being a tool driven approach. The suitable for Ongoing releases are continually checked applications that Update and released into the environment require constant on an ongoing basis. release updating.
6. POLICY
Release Management must work closely with the IT Change Management process and be subject to Change approval. Each release must have an associated Request for Change Record (RFC). All releases should strive to minimise the amount of business disruption experienced. By default any auto update feature of an application should be disabled before deployment.
7. OVERALL RELEASE MANAGEMENT CONSIDERATIONS
The following considerations have been identified as having an impact on the overall Release Management Strategy:
That all process activities can be evidenced for further review and audit.
Version: 1.0.0 Page 3 of 5 Release Management Strategy This is a controlled document. Prior to using this document, IT MUST BE CHECKED against the current revision held in the DAL
That all measures balance the resource required and risk of deploying releases against the potential threats to Council services – it may be appropriate NOT to roll out some or all releases if the threat of disruption outweighs the perceived benefit. That the frequency of releases is considered to ensure the effective use of resources – it may be appropriate to batch a series of fixes or upgrades into a more significant release. It is acknowledged that the emphasis on these items will differ from one technical area to another, e.g. Deployment of end-point security updates may be heavily automated and require little or no intervention, but it is important that this is noted and documented initially. Releases should be deployed in a timely manner. Where possible where a system experiences a high level of releases these should be bundled together for deployment at a single time.
8. RELEASE CATERGORISATION
Releases are categorised as:
Normal A normal release is defined as the bundling together of the relevant updates for that period at one time.
Emergency A release is considered Emergency when it meets ALL of the following criteria:-
The requirement to update is unplanned and unforeseen. The issue to be resolved by the update itself is deemed to have a ‘Business Critical Impact’ and is seen to be necessary to prevent disruption or further disruption to the production environment. Please note that a ‘Business Critical Impact’ could also include the following areas:- . Changes required by Security. . Changes required by a sudden change in legislation / regulatory rules. The release has been deemed to be urgent and has been approved by the Change Advisory Board (CAB).
9. RELEASE TESTING
Releases should be tested from a number of different considerations. The following areas have been identified as being relevant to Release Management:
Version: 1.0.0 Page 4 of 5 Release Management Strategy This is a controlled document. Prior to using this document, IT MUST BE CHECKED against the current revision held in the DAL
Testing Type Description Does the updated application still Application Integration work with regards to other applications that interact with it? Does the release actually deliver the Benefits Realisation change or improvement expected? Does the updated application still Hardware Compatibility work on the relevant hardware? Does the updated application still User Acceptance Testing perform as required by the User? Does the update actually perform the Functionality Testing required functionality? Will the rollout of the update cause any issues? (Note: The bandwidth Rollout Testing requirements should be considered here) Is it possible to rollback to a controlled Rollback Testing point if the update does not function as required? Does the inclusion of the update within the overall quarterly release Release Integration Testing cause any of the other releases to fail?
Version: 1.0.0 Page 5 of 5 Release Management Strategy