Release Management and change management understanding questions for the experts.

[xjxx]

Hi Everyone.

I am new here and hope to find some support to understand things to release management.

My first thing I want to understand does release management apply to (or need to be followed when downloading the following):

Question A:

1- deploy Windows or linux or aix or database patch.

2- upgrade windows OS (win2012 --> win2022) or Linux OS (7 to 8_) or AIX (7.1 to 7.2) or Database (18c to 19c) from version to version.

3- Upgrade an existing application (that is NOT internally developed) or install its related patches. [that application will have a new version from the vendor]

4- introduce a totally new application (that is NOT internally developed) that will provide services to the organization staff.

5- introduce a totally new application (that is NOT internally developed) that will provide services to the organization customers.

6- Introduce a new feature (by adding module or upgrade of an application (that is NOT internally developed) to customers or internal staff.

7- Enabling a service that was already exist but was originally disabled.

8- Modify a script or a stored procedure or Middleware (e.g. App Connect) (internally developed) workflow code as a result of bug/incident/ or performance issue.

9- Modify a script or a stored procedure or Middleware (e.g. App Connect) (internally developed) workflow code as a result of changing business logic and flow.

10- modify the front layer (CSS/HTML) Code of an application (Which is being done by the vendor) while the backend is internally developed and not changed.

11- modify the front layer (CSS/HTML) layout Code of an application (by Internal development team).

12- Modify the configuration file or settings of an internally developed application.

13- Introduce a totally new application that IS developed internally to Customer or internal Staff.

14- Upgrade an internally developed application.

15- Patch an internally developed application.

16- enhance or add services of internally developed application.

17- Migrate database data from Application X database to Application Y database.

Question B:

Are Code Versioning (and if the release will be minor or major) and code repository are related and part of the release management process?

Question C:

Is controlling and ensuring the code hash value between production/UAT is part of the release management process?

Question D :

Before the release management process reaches the deployment phase, the CRQ should be raised in the change management process for the launch of this release and when the CRQ reaches implementation phase then at that point the deployment phase as part of the release management flow will start, is this understanding correct?

Question E:

If "D" is accurate then can ServiceNow Release Management v2 Plugin be used to initiate the CRQ when the development testing is complete with properly referencing and linking both the Release # and CRQ #

Question F:

Why do I need testing in release management if this will be covered as part of the change management process?

Question G:

Is there multiple type of releases that each might follow different approach? e.g. depending if its standard, minor, major, critical, emergency or this should be controlled through change management process?

Question H:

Is there a relation between releases or release management and data migration? Or is this only applicable if I am decommissioning Application 'A' that is internally developed and moving it to application 'B' that is ALSO Internally developed ?

Question I:

What do the following actually referring to:

a- change release strategy and approach. << is this related to deployment!! (canary, targeted, ring deployment, etc)

b- change release schedule and logistics. << not sure about logistics part. What will be cover there ! what supposed to happen as is this part of development, deployment, planning!!

Question J:

When we say a release consist of multiple changes this does not mean I will have multiple CRQs and then combine them to a release, but rather it is multiple requirements such as adding x, remove B, enhance Z, Fix T will be done in one single development and deployed as part of the coming release that will follow the release management and will have a single CRQ in the change management process, is this understanding correct ?

Question K:

If a release will be deployed in phases or canary/targeted, should I raise multiple CRQs with the same details and process of approvals and testing ?

I think it depend on the deployment, for example, If I will install on 1 server out of 3, then a new CRQ will be created, with same test results but following the same approvals, the difference between the first and second is the asset where the code will be deployed. However, if the code will be deployed on all servers but the scope will be controlled through a config setting or code modification then then new CRQ will be created but not for deployment but for config change CRQ, but need to be linked to the release reference as the release will be fully deployed when all users are using the new code.

Then can ServiceNow Release Management v2 link those CRQs to the same release reference due to multiple deployments phases ?

Question L:

change roll-out and roll-back procedures and requiring duplicating the release installation to DR will be part of the change management and no need to be part of release management itself, is this correct ?

and change roll-out procedure is the steps to be done (e.g. the file location, the commands that need to be run to start the code and config changes to complete the deployment) which is different than the release strategy and approach, is this correct ?

Thats it! Hope I can have better view of releases and changes by understanding the answers of these.