Release and Deployment Management

Release Management process is supported by a SM workflow cartridge that enables the execution of the process according to the ITIL and ISO/IEC 20000 guidelines.

Of course the preconfigured process (the workflow cartridge) is just an accelerator and the tuning / completion of the initial configuration will still be required. To this aim, the Workflow Engine guide may be useful.

IMPORTANT NOTE: the configuration below is only one of the possible configuration to deal with the release management process. The need for a different behaviour of the process may be fulfilled by simple changes of the configuration.

Operational model

The preconfigured process has the objective to facilitate and support the effective and efficient execution of releases. At the core of the process configuration is the following operational model.

Release Management operational model

The requester, a service manager, an authorized member of the service desk or a technical team member (e.g. a developer) or the change Management process requires a new release. The release manager takes in charge it and assigns an owner who coordinates all the tasks needed to fulfil the release. If necessary, the owner requests the releasee authorizations to the change authority. Finally, he/she activates the deployment change process in order to complete the installation of the release in a target environment (e.g. test, production).

Roles

For this process, the following organizational roles are defined:

Organizational role	Description	itmSUITE® role mapping
Requester	Opens requests for releases on behalf of himself/herself or for a third party	This role is mapped on: service managers (see after); service desk members (system resources with user of user type "Resource"; the login identifier of this user is "SDSpecialist"); technical team members (see after).
Release owner	Requires release approval to the change authority after its assessment is completed Assign tasks to be performed to complete the release (e.g. opens deployment changes) Watches over and monitors the release along all its life cycle ensuring target service levels are achieved Activates escalation/ routing/ requests Manages all the communications with the requester Checks the implementation and sets the releasee to completed Closes the release after completing the final checks	This role is assigned to the manager of the group "Release Management"; the login identifier of this user is "ReleaseManager".
Technical team member	A technical team member may first of all be a requester (see before). However he/she may play an active role in the preparation and installation of the release. In detail He/she receives the notification on the assignment of an activity concerning a release (e.g. conducting the assessment or designing/implementing it) Carries out the assigned tasks Notices when completed or unable to complete	There are several technical teams predefined for different domains. The following table shows which users are members of each team. Domain Group Member users Application management "Application Management" "AppManager" "AppSpecialist" Personal devices management "Personal Management" "PersonalManager" "PersonalSpecialist" Network management "Network Management" "NetManager" "NetSpecialist" Server management "Server Management" "ServerManager" "ServerSpecialist"
Technical team manager	Receives the notification about the assignment of the release to his/her team in order to implement it Assign the member of his/her team who should work on it (this can be done by setting the ticket worker or creating and assigning ticket activities) Watches over and monitors the work of his/her team	There are several technical teams predefined for different domains. The following table shows which users are set as solution group manager for each domain. Domain Group Group manager Application management "Application Management" User "AppManager". Personal devices management "Personal Management" User "Personal Manager". Network management "Network Management" User "NetManager". Server management "Server Management" User "ServerManager".
Service manager	The service manager may act as a requester of a release (see before).	This role is mapped on the managers of the groups . There are different service managers configured for specific services. See Services section in this page for further information.
Change authority	Approves the release implementation Approves the releasee deployment	This role is mapped based on the required authorization and release classification. For release implementation authorization: Release Type Change authority "Emergency" Service manager "Minor" Service manager "Major" CAB The CAB is mapped on a group: "CAB". For release deployment authorization: Change Type Change authority "Emergency" Service manager "Minor" Release manager "Major" Service manager

Process

As for all workflows, new releases can be created by using the self service portal, accessible by means of Self Service menu.

The following requests which trigger a new instance of the release management process are configured and available in the self service portal:

Self service topic	Self service category	Self service request	Authorized roles
"Applications"	"Application Management"	"Release" (open a release)	Requesters

A release may also be automatically opened during the execution of the change management process.

A workflow is configured to support the release management process. The workflow is characterized by workflow statuses and workflow transitions. The figures below illustrate the process.

Release management process (1 of 3).

Release management process (2 of 3).

Release management process (3 of 3).

The table below explains the meaning of each workflow status.

Workflow status	Description
"Default"	A preliminary status which is displayed when a release is created.
"Opened"	The release has been recorded.
"Requested"	The release is confirmed and has been requested.
"In Analysis"	The release assessment and planning is ongoing.
"Implementation Approval Requested"	The release approval request for implementation is submitted to the change authority.
"Approved"	The release is approved for implementation.
"Not Approved"	The release is not approved for implementation.
"In Progress"	The release implementation is ongoing.
"Ready for Test"	The release is ready for testing.
"In Test"	The release testing is ongoing.
"Deployment Approval Requested"	The release approval request for deployment is submitted to the change authority.
"Deployment Approved"	The release is approved for deployment.
"Completed"	The release is completed.
"Change Review"	The release review is ongoing.
"Cancelled"	The release is not confirmed and, therefore, cancelled.
"Suspended"	The release execution is temporarily suspended. In this status service levels calculation are suspended too.
"Aborted"	The release execution is aborted.
"Closed"	The release closure has been confirmed.

And finally the table below explains the roles authorized to execute the workflow transitions.

Source status	Destination status	Authorized executors	Comment
"Default"	"Opened"	Requester	See the self service portal configuration previously described.
"Opened"	"Requested"	Requester, service manager.
"Opened"	"Cancelled"	Requester, service manager.
"Requested"	"Opened"	Requester, service manager..
"Requested"	"Cancelled"	Requester, service manager, release owner.
"Requested"	"In Analysis"	Release owner.
"Deployment Approved"	"Aborted"	Release owner.
"In Analysis"	"Requested"	Release owner.
"In Analysis"	"Approval Requested"	Release owner.
"In Analysis"	"Cancelled"	Release owner.
"Approval Requested"	"Approved"	Change authority.	Depending on release classification (see roles for more details).
"Approval Requested"	"Not Approved"	Change authority.	Depending on release classification (see roles for more details).
"Approval Requested"	"In Analysis"	Release owner.
"Not Approved"	"Cancelled"	Release owner.
"Approved"	"In Progress"	Release owner, technical team member.
"Approved"	"Suspended"	Release owner.
"Approved"	"Aborted"	Release owner.
"Suspended"	"In Progress"	Release owner.
"In progress"	"Suspended"	Release owner.
"In progress"	"Aborted"	Release owner.
"In progress"	"Ready for Test"	Release owner, technical team member.
"In progress"	"In Test"	Seleaseervice manager, change owner, technical team member.
"In progress"	"Deployment Approval Requested"	Release owner.
"In progress"	"Completed"	Release owner.
"Ready for Test"	"In Test"	Seleaservice manager, change owner, technical team member.
"Ready for Test"	"Suspended"	Release owner.
"Ready for Test"	"Aborted"	Release owner.
"In Test"	"Deployment Approval Requested"	Release owner.
"In Test"	"Suspended"	Release owner.
"In Test"	"Aborted"	Release owner.
"Deployment Approval Requested"	"Deployment Approved"	Change authority.
"Deployment Approval Requested"	"Suspended"	Release owner.
"Deployment Approval Requested"	"Aborted"	Release owner.
"Deployment Approved"	"Completed"	Release owner.
"Completed"	"Change Review"	Release owner.
"Completed"	"Closed"	Release owner.
"Change review"	"Closed"	Release owner.
"Not Approved"	"In Analysis"	Release owner.

Related processes

Several other IT Service Management processes are related to the release management one. Some basic interfaces are provided. The tab Related Items of the release and, in particular, the sub tab Tickets of it allows to view all the existing relationships between the release and other processes (managed through tickets).

Incident management

The relationship is indirect: a release may be related to changes which implement the solution of incidents.

Problem management

The relationship is indirect: a release may be related to changes which implement the solution of problems.

Asset management and configuration management

It is possible to relate configuration items to a release by using the tab Related Items and, in particular, the sub tab Configuration Items. The ASM and/or CMS modules features are made available here (e.g. view of configuration item details, configuration exploration or impact analysis).

Change management

A release may include one or more changes. The relationship between a release and and change can be created from the change but is is more frequently created working from the release. In any case, the relation from the change can be created from the tickets tab Related Items and, in particular, the sub tab Configuration Items by using the ADD EXISTING or SELF SERVICE commands.

Deployment Change

A deployment change may be opened automatically, by means of a command button, in specific statuses of the release. Once opened, the deployment change is kept linked to the

Services

Different services are configured for different change domain areas as illustrated in the following table.

Incidents domain areas	Service	Service manager
Application management	Only one application, and the related service ("itmCLOUD") is configured.	The user "servicemanager" is configured as service manager.
Personal devices management	"Personal Device Management".	The user "personalmanager" is configured as service manager.
Network management	"Network Management"	The user "netmanager" is configured as service manager.
Server management	"Server Management"	The user "servermanager" is configured as service manager.

Management information

Many management information are available as fields in the change management configured form. The following table illustrates the intended use of key information and its behaviour. NOTE: information are available (visible) and can be modified according to a specific configuration which is meant to be suitable for the organizational roles involved in the process.

Information group or tab	Field	Purpose	Comments
General Information	Ticket Op Status	To show the operational status of the change, see workflow statuses in Process section of this page.	Status changes are performed by means of the Save&Next command.
General Information	Request Name	To show the SRCS request invoked
General Information	Short Description	To provide a short description of the change.	Always visible.
General Information	Requester	To identify the name of the requester (who has requested the change).	A list is presented, influenced by.... TBC
General Information	Creation Date	To show the date and time the change was created.	This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information	Edit Date	To show the date and time the change was last updated.	This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information	Creation User	To show the user who created the change.	This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
General Information	Edit User	To show the user who updated the change last.	This information is automatically recorded and cannot be manually changed. See History tab for more detailed tracking information.
Ticket Classification	Project/Service	To show the service (or project) to which the change is related.	This is automatically set at open time and can't be modified.
Ticket Classification	Ticket Type	To show the type of workflow executed.	This is automatically set at open time and can't be modified.
Ticket Classification	Chage Area Change Objective Change Type Change Category	To set the change key classification information.This is used for statistic reasons but the Change Category may also be configured to drive the change authorization.	Change Area, Change Objective and Change Type are independent fields. Change Category is available only if Change Type is set to "Normal": In such a case, its value is influenced by the change assessment fields (see below). The classification information initially provided can be changed.
Ticket Classification	Change Scope	To set the change scope.This is typically used for statistic reasons.	The classification information initially provided can be changed.
Ticket Classification	Service impact Capacity impact Security impact Cost estimation Performance impact	These fields are the change assessment elements. The values given will influence the Change Category value.	The classification information initially provided (number and content of fields) as well as the rules to influence the Change Category can be changed.
Prioritisation & Planning	Required Solution Date	To provide the date of change implementation required by the Requester.
Prioritisation & Planning	User Priority	To provide the priority given to the change by the Requester.	A four level scale is set but it can be changed.
Prioritisation & Planning	Forecasted Solution Date	To provide the date of change implementation forecasted.
Prioritisation & Planning	Forecasted Solution Date	To set the forecasted resolution date and time for the change.
Ownership and Groups	Master SG	To define the supervising team.	This is set by the service manager and mandatory from the Ticket Op Status "In Analysis".
Ownership and Groups	Solution Group	To define the team to which the change is assigned for analysis and/or implementation.	This is set by the service manager and mandatory from the Ticket Op Status "Approval Requested".
Ownership and Groups	Owner	To define who is the change owner who should monitor the lifecycle of the change.	This is set by the service manager and mandatory from the Ticket Op Status "In Analysis". He/she can be changed by the service manager and the Owner him/herseilf.
Ticket Details	Description	To provide a more detailed description of the change.	An auto tracking field is used enabling to view the user who has updated.
Ticket Details	Analysis	To provide a detailed analysis of the assessment of the change.	An auto tracking field is used enabling to view the user who has updated.
Ticket Details	Solution	To describe the required implementation for the change.	An auto tracking field is used enabling to view the user who has updated.
Ticket Details	Comments	To provide helpful comments.	An auto tracking field is used enabling to view the user who has updated.

Fields can be mandatory to save the change in some workflow statuses. These fields are highlighted with a red asterisk.

Views

The following views are made available in the Tickets area of the home page:

View	Content	Requester	Change owner	Technical team	Service manager	Change authority
Changes completed	Changes in statuses "Completed", "In Review".	X
Changes requested	Changes in status "Requested".				X
Changes owned	Changes in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where Owner is the logged resource.		X
Changes routed to my team	Changes in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where Solution Group is the solution group to which the logged resource belongs to.			X
Changes assigned to me	Changes in all the statuses but "Opened", "Cancelled", "Aborted", "Closed" where the Ticket Worker is the logged resource.			X
Changes suspended	Changes in status "Suspended".		X		X
Changes to review	Changes in status "Completed" where Change Type is "Emergency" or where Change Type is "Normal" and Change Category" Significant"..		X		X
Changes to authorize for implementation	Changes in status "Implementation Approval Requested".					X
Changes to authorize for deployment	Changes in status "Deployment Approval Requested".					X
Changes evaluated by Change Authority	Changes in status "Approved" or "Not Approved".		X		X
Changes approved for deployment	Chnages in status "Deployment Approved".		X		X

Additionally, the following views are made available in the Change menu for all the organizational roles:

View	Content
Changes active	Changes in all the statuses but "Cancelled", "Aborted", "Suspended", "Closed"
Changes suspended	Changes in status "Suspended
Changes closed	Changes in status "Closed"
Changes cancelled	Changes in status "Cancelled"

Notifications

The following notifications are configured:

Trigger	Recipients	Purpose
A change is requested	Service manager	Alert that there is a change to manage.
A change is assigned a owner	Change owner	Alert that the change was assigned to him/her.
A solution group is assigned or changed for the change	Solution group manager	Alert that there are resource(s) to allocate to manage the change.
A change review shall be executed (the change is in workflow status "Change Review")	Change owner, service manager	Alert that a change review is to be done.
A change is completed	The change creator, the requester	Alert that the change is implemented.
A ticket worker is assigned	The assigned ticket worker	Alert that there is work to be done.
A change is suspended	The change creator, the requester, the service manager, the change owner	Alert that the change is suspended.
An change is closed	The change creator, the requester, the service manager, the change owner	Alert that the change has been closed.
A change is cancelled	The change creator, the requester, the service manager, the change owner	Alert that the change has been cancelled.
A change implementation approval has been requested	Change authority	Alert that a change implementation request has to be examined.
A change implementation approval request has been examined	Change owner, service manager	Alert that the change authority has given a feedback on a change implementation request.
A change deployment approval has been requested	Change authority	Alert that a change deployment request has to be examined.
A change deployment approval request has been examined	Change owner, service manager	Alert that the change authority has given a feedback on a change deployment request.

Reporting

A set of standard reports are made available for the change management process. It is not required to have the REP module to use them, however the module is required if new or changed reports are needed. The available reports are placed under Change/Reporting menu.

The following table lists the reports available by default and their visibility:

Report name	Content	Access
Change per category - trend	An histogram showing the change volumes per category monthly trend.	Service managers and technical team members.
Change per category - volume	A pie containing the split of changes per category.	Service managers and technical team members.
Change per service - trend	An histogram showing the change volumes per service monthly trend.	Service managers and technical team members.
Change per service - volume	A pie containing the split of changes per service.	Service managers and technical team members.
Change per service/category - volume	An histogram showing the changes volume per service and category.	Service managers and technical team members.
Change - analysis time	A pie showing the percentage of changes respecting the target defined for the "Analysis time"* objective (the time elapsed from the "Requested" to the "In Analysis" workflow status.	Service managers and technical team members.

* "Analysis time" is defined within the OCE module.

A basic form of reporting is also provided by views. Views basically allow to list changes and their attributes but may also be configured to calculates sums, averages on some of them. The available views are illustrated in the dedicated section of this page.

Examples of use

In this section some examples of use of the configured change management process are given.

If you get lost, any time use the EXPLORE WORKFLOW command of the change management form. This enables to view the status of the workflow as shown in the figure below. By clicking on a relationship between workflow statuses, roles and users enabled to perform it are presented.

Explore Workflow window

NOTE: the EXPLORE WORKFLOW command is available only if the ticket is first saved.

For more information on how to use any workflows, including incident management, please refer to the workflow execution guide.

Create and request a new change as a final user

1. Login as "finaluser" user
2. Activate the Self Service menu
3. Choose a self service topic, self service category and finally "Change" as self service request (this determines the creation of a new change)
4. Fill the change form, at least with mandatory fields, and save with the SAVE command (the change is now in workflow status "Opened")
5. Set the change in workflow status "Requested" with the SAVE & NEXT command

You have now saved the change, take note of the ticket number for further reference and use.

Assign a change for analysis as a service manager

1. Login as "servicemanager"
2. Open the the desired change; you can do it quickly either by
   • Access the "Changes Requested" view in the Tickets area of the home page and pick a change
   • Access the Change/Changes active menu and pick a chanve in workflow status "Requested" among those listed
   • Insert the reference number of a change in workflow status "Requested" in Quick Search, after selecting the search context "Ticket"
3. Assign the key roles
   • Fill the change form with Owner, Solution Group and, may be, Master Solution Group, Ticket Worker,
   • Pressing the SAVE & NEXT command, choose the "1. Assign ticket" workflow transition

The change is now in workflow status "In Analysis".