Skip to content

Platform Changes

# Platform Changes

Purpose

The purpose of this document is to describe the handling of Change management in Operation phase.

Implementation Plan and Report will be drafted in QualityDocs for capturing the release activities for the type of changes defined in the Manage IT Infrastructure SOP [Q216301]. Wherever changes to the platform is impacting the User requirements/Requirement Specification, Service Owner (SO Delegate) will be involved in the approval of the Requirement Specifications wiki. QA shall be informed/involved about the Change in case of new requirements or any drastic impact to the existing User Requirements and shall be involved for the formal approval at plan and report level (whenever created).

In rest of the scenarios, below defined Change management process is followed.

Rationalizing Risk & Change Impact

Before a detailed assessment and description of the change implementation and test approach, the following Risk assessment must be made by Platform Architect/Development Team involved in implementing the Change. - Impact on the qualified state of KaaS Infrastructure - ITRA impact - End-user impact - Functionality criticality - Impact on the Operation process

This assessment is captured in the ServiceNow Change (CHG) under the 'Risk and analysis' section. The change description remains in a 'Scheduled' state until after its production implementation, review, and closure. Deployment in lower environments can be performed before CHG is scheduled - depending on risk assessment. Execution details, including run IDs and reporting details are captured in 'Closure information' before closing the Change ticket.

Change Flow

The guidance for Change creation is same as described in Standard Changes - Overview

QA Involvement

QA only needs to be involved when there is a significant change on existing core functionality or the introduction of new requirement(s). In such cases QA will perform the CHG review and approval.

As per Manage IT Infrastructure SOP(Q216301) for qualified IT infrastructure QA must approve implementation, release and closing of the following types of IT changes:

  • Initial qualification
  • Changes that alter intended use
  • Changes that alter the gross risk impact/likelihood of the IT infrastructure
  • Change of supplier/product
  • Retirement of the IT infrastructure

Testing approach for CI/CD setup in KaaS

KaaS platform is formally qualified in detail by verifying key functionalities and the configurations are controlled and maintained through CILs in ADO. By considering the 'Qualify once and Deploy many' approach as stated in Manage IT Infrastructure SOP, Q216301, risk based unscripted testing approach is leveraged wherever possible.

Pre-implementation steps:

  • Change shall be created in Service Now by IT Service Manager for the requirement to be deployed in production. Change shall be implemented in production once it is in "Implement" state in Service Now.
  • During the birth of a feature/ during Sprint Planning/Refinement, the requirement shall be discussed and based on the impact, risk, complexity decision shall be made on which testing approach shall be chosen (Scripted /Unscripted Testing). The decision responsible would be PO and SM.
  • Scripted testing: Dedicated Test Plan would be created in ADO where test steps and expected results are documented before test execution and pre-approved for test scenarios. The Test Plan field in ADO shall capture the high-level overview of the approach and the reference to the Test Plan created. The same test cases are then executed to conclude and record the testing performed. This is the preferred method for features that are being tested for the first time and any major changes brought into the feature RS/DS.
  • Unscripted testing: This testing requires the tester to be highly knowledgeable about the IT infrastructure that is tested meaning that the tester must be an SME of what is implemented and their domain knowledge is utilized for infrastructure installation and configuration. No formal Test Plans will be created for this type of testing in ADO. The Test Plan field in the Change shall capture the scenarios that are being tested and explicitly mention that the testing/verification evidences would be attached to the Change. All the relevant details for the change implementation like pull requests, pipeline run IDs and CIL tag verification are verified through closure notes updated in the change ticket by QC and SM before closing the change.

Note: Unscripted Testing approach is followed for changes that have impact only on lower-level FS/DS updates. Any drastic changes at URS/Solution Design level need to be thoroughly assessed for the risk impact and scripted testing approach shall be considered.

Please refer Verification Strategy - Overview for detailed flow on both types of Testing.

Release

Technical go-live: The Technical go-live will be done via approval of Technical Go-Live Test Report by PO/SM in ADO after concluding all the pIV test runs.

Business go-live: Business go-live will be concluded via approval of Change Ticket in ServiceNow or in QualityDocs whenever SO and QA involved in CHG review process.

Release information is based on assessment of impact and criticality and may be communicated directly to users or via Viva Engage (Yammer).